Linus Torvalds Posts on comp.os.linux Searched Groups for group:comp.os.linux author:Linus author:Torvalds. Results 401 - 434 of 434. =============================================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: HD timeout Errors (with .95a) Keywords: IDE Message-ID: <1992Apr3.144129.15122@klaava.Helsinki.FI> Date: 3 Apr 92 14:41:29 GMT References: <1992Apr3.030517.29450@afterlife.ncsc.mil> Organization: University of Helsinki Lines: 25 In article <1992Apr3.030517.29450@afterlife.ncsc.mil> sdbaker@afterlife.ncsc.mil (Stewart Baker) writes: >Is there anyone else having problems with their disk in .95a? > [ description deleted ] I'm afraid there are people still having problems with the 0.95a harddisk drivers: the problems show up in "unexpected HD interrupt" and "HD timeout" messages. These messages sometimes result in read-errors, it seems: general protection errors and sometimes even bad filesystems. I'll make a new alpha-patch available tomorrow, which has some corrections to the harddisk driver: they aren't guaranteed to help you, but I hope the few persons experiencing these errors will try them out and report to me what happened. The upcoming alpha-patches will also contain other corrections: the 387-emulation had bugs (corrections were already sent to the gcc-2 beta-testers) and there has been some further work done on the VFS-code (thanks to entropy and card) as well as some other corrections (hedrick, bruce evans etc pointed out bugs..) I'm afraid the patches will be against a clean 0.95a once more: people with other patches might have problems. The ps-patches are incorporated, btw. Linus ================================= ================================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Help, can't compile 0.95a! Message-ID: <1992Apr3.212741.3018@klaava.Helsinki.FI> Date: 3 Apr 92 21:27:41 GMT References: <1192@lysator.liu.se> <03.04.92.020516.223@cogsci.cog.jhu.edu> Organization: University of Helsinki Lines: 44 In article <03.04.92.020516.223@cogsci.cog.jhu.edu> wjb@cogsci.cog.jhu.edu (Bill Bogstad) writes: > > I have a 8 Meg system and also am having problems compiling fork.c. >I would have thought that would have been sufficient.... Ok, the problem isn't memory: it's gcc-1.40. For some strange reason the older gcc runs out of registers when optimizing some of the files in the linux source distribution, and dies. This one isn't the same bug as the "unknown insn" which was due to my hacks in the earlier 1.40 - this one seems to be a genuine gcc bug. Linux 0.95a is compileable with the older gcc if you just add the flag "-fcombine-regs" to the command line. In fact, the only thing you need to do is to remove a "#" from the makefiles: the line #GCC_OPT = -fcombine-regs should be uncommented, and gcc-1.40 will have no problems compiling the source. This was documented in some of the release-notes for 0.95, but I guess I forgot it for 0.95a. Why remove the flag in the first place I hear you say? Simply because gcc-2 doesn't understand -fcombine-regs, as it seems to do the optimizations even without asking. There are other things I had to change in the source to get gcc-2 to compile it, but this is the only problem that made the old gcc choke. With the advent of an official gcc-2.1 (this weekend?), people might want to change to that one: note however that gcc-2.1 is about twice as big as 1.40, so it's going to be slower on machines that swap... People with just 2M of mem might not want to upgrade (*). I like the changes to 2.1: the code quality seems to be a lot better (esp floating point). On a slightly related note: the as-binary in newgcc has been reported by several people to have problems. Getting as from the original gcc-distribution by me (gccbin.tar.Z) might be a good idea if you have problems with the newgcc version. Linus (*) Even with only 2M of mem, using gcc-2 has it's good points. The shared libraries should cut down on memory use as well as loading time and disk-space use. Shared libraries work even with 1.40 if you know how to build them, but 2.1 does it all automatically... ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: What is linux? Keywords: linux Message-ID: <1992Apr3.214400.3551@klaava.Helsinki.FI> Date: 3 Apr 92 21:44:00 GMT References: <1992Apr1.182702.8464@colorado.edu> <1992Apr02.135130.26689@watson.ibm.com> Organization: University of Helsinki Lines: 28 In article IMHW400@INDYVAX.IUPUI.EDU (Mark H. Wood) writes: >In article <1992Apr02.135130.26689@watson.ibm.com> lpickup@xanadu.btv.ibm.com (Lance Pickup) writes: > >>While not part of the original question, it's worth mentioning that >>Linux requires an ISA bus--no MCA )-; > >Is this just because nobody's done it, or LINUX' structure would make it too >difficult, or is it a matter of principle :-) ? Seriously, if anybody is >working on MCA mods, I'd like to know. If not, I may take a stab at it >myself, so my poor underemployed PS/2 can have a real operating system, in >addition to MeSs-DOS. It's not due to some internal linux-design: linux does count on a 386+ processor, but there isn't any heavy kernel dependancy on the AT-bus. HOWEVER: most device driver will probably have to be changed to some degree, but I haven't got the slightest idea of what is needed. The minimum needed to make a PS/2 port is a very thorough knowledge of the interrupt and IO system of the MCA systems, as well as patience and a feel for kernel programming (debugging is /hell/ when nothing works - no debugger I know of can follow the code from real mode to protected mode and paging-setup etc - you'd probably need an emulator). I can help with questions about the current code, but I have /no/ idea of what the microchannel architecture changed with respect to the ISA standard, so you are essentially on your own in that respect. I assume DMA, A20 etc have changed - I know the keyboard seems to work differently etc... Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Since I haven't seen an FAQ... Message-ID: <1992Apr4.102225.13174@klaava.Helsinki.FI> Date: 4 Apr 92 10:22:25 GMT References: <1992Apr3.190450.28708@pony.Ingres.COM> Organization: University of Helsinki Lines: 138 In article <1992Apr3.190450.28708@pony.Ingres.COM> sergio@Ingres.COM (Sergio L Aponte) writes: > > Can somebody give me a two-three liner description of what is LINUX > and what hardware it runs on? Ok, this has come up so many times I'd better send out the info-sheet. The FAQ is maintained by corsini@?? and he'll send out the newest version just as soon as this newsgroup gets that far. This info-sheet is basically the old 0.12 info-sheet with very minor modifications: I've changed it slightly, but it's not completely up to date. Linus ---------- LINUX INFORMATION SHEET (last updated 13 Jan 1992 (with changes by Linus 4.4.92)) 1. WHAT IS LINUX 0.95a LINUX 0.95a is a freely distributable UNIX clone. It implements a subset of System V and POSIX functionality. LINUX has been written from scratch, and therefore does not contain any AT&T or MINIX code--not in the kernel, the compiler, the utilities, or the libraries. For this reason it can be made available with complete source code by anonymous FTP. LINUX runs only on 386/486 AT-bus machines; porting to non-Intel architectures is likely to be difficult, as the kernel makes extensive use of 386 memory management and task primitives. Version 0.95a is still a beta release, but it already provides much of the functionality of a System V.3 kernel. For example, various users have been able to port programs such as bison/flex without having to modify code at all. Another indication of its maturity is that it is now possible to do LINUX kernel development using LINUX itself and freely-available programming tools. 2. LINUX features - System call compatible with a subset of System V and POSIX - Full multiprogramming (multiple programs can run at once) - Memory paging with copy-on-write - Demand loading of executables - Page sharing of executables - Virtual memory: swapping to disk when out of RAM - POSIX job control - virtual consoles - pty's - some 387-emulation - ANSI compliant C compiler (gcc) - A complete set of compiler writing tools (bison as yacc-replacement, flex as lex replacement) - The GNU 'Bourne again' shell (bash) (as well as 'ash', 'rc' etc) - Micro emacs - most utilities you need for development (cat, cp, kermit, ls, make, etc.) - Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.) - Currently 6 national keyboards: Finnish/US/German/French/British/Danish - Full source code (in C) for the OS is freely distributable - Full source code of the tools can be gotten from many anonymous ftp sites (Almost the entire suite of GNU programs has been ported to Linux.) - Runs in protected mode on 386 and above - Support for extended memory up to 16M on 386 and above - RS-232 serial line support with terminal emulation, kermit, zmodem, etc. - Supports the real time clock 3. HARDWARE REQUIRED - A 386 or 486 machine with an AT-bus. (EISA will probably work, also, but you will need an AT-bus hard disk controller.) Both DX and SX processors will work. - A hard disk implementing the standard AT hard disk interface -- for example, an IDE drive. In addition, some SCSI drives are supported with additional kernel patches. - A high-density disk drive--either 5.25" (1.2MB) or 3.5" (1.44MB). - At least 2 megabytes of RAM. (LINUX will boot in 2 Mb. To use gcc 4 MB is a good idea.) - Any video card of the following: Hercules,CGA,EGA,VGA In addition, LINUX supports - Up to four serial lines (2 active at a time) - A real time clock 4. PARTIAL LIST OF UTILITIES INCLUDED IN OR AVAILABLE FOR LINUX 0.95a - The MTOOLS package (reading/writing to DOS filesystems) - The complete GNU filetools (ls, cat, cp, mv, ...) - The GNU C and C++ compiler with GNU assembler, linker, ar, ... - bison - flex - rcs - pmake (BSD 4.3 Reno/BSD 4.4 make) - kermit - Micro emacs - less - mkfs - fsck - mount/umount - TeX, dvips - and lots more... 5. LINUX BINARIES The LINUX binaries and sources are available at several different anonymous FTP sites. The biggest are: nic.funet.fi:/pub/OS/Linux tsx-11.mit.edu:/pub/linux 6. LEGAL STATUS OF LINUX Although LINUX is supplied with the complete source code, it is copyrighted software. Unlike MINIX, however, it is available for free, provided you obey to the rules specified in the LINUX copyright. Linux is (C) Linus Torvalds, but the copyright is the GNU copyleft: get a copy of the copyleft at your nearest ftp-archive.. 7. NEWS ABOUT LINUX There are now two newsgroups devoted to linux articles: an older alt.os.linux and the new comp.os.linux group. The alt-group will be phased out as the comp-group gets a wider propagation. Additionally, there are a couple of mailing-lists: linux-activists@niksula.hut.fi is the original mailing-list, and it now supports sub-threads (notably the gcc-2 beta-testing list). There is also a linux-standards mailing list as well as a newsgroup-service for those that can get mail but are unable to read the newsgroups. For the current status of LINUX, do a "finger torvalds@kruuna.helsinki.fi". 8. FUTURE PLANS Work is underway on LINUX version 1.0, which will close some of the gaps in the present implementation. Various people are currently working on: - A more complete virtual filesystem layer - STREAMS - Interprocess communication - IEEE POSIX P1003.1 / P1003.2 compatibility - more complete SCSI support If you want to help, mail the various activists or post to the newsgroups. ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux,alt.os.linux Subject: Re: Second 0.95a alpha-patch Summary: include-file changes Message-ID: <1992Apr5.174430.17408@klaava.Helsinki.FI> Date: 5 Apr 92 17:44:30 GMT References: <1992Apr4.144210.17833@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 51 I forgot to mention some of the changes this alpha-patch brings to the user: the kernel include-files have been slightly changed in a couple of cases, which can result in unexpected behaviour... a.out.h is now the latest GNU a.out.h, and it seems to have slightly different magic-number handling than the original 386-minix version I used for older versions. Without recompiling the kernel with the new a.out.h, programs linked with the new binutils will not run (unable to execute binary file errors). This just means that even if you don't use the patch in any other capacity, you had better upgrade to the new a.out.h, or newer programs won't necessarily run. Right now there are no such binaries available, but when gcc2 gets more used, they will show up. The other change is that limits.h and sys/dirent.h are now part of the kernel include-files: they were needed for the readdir() system call. Normally this wouldn't change anything, but there is also a slight change in limits.h - NAME_MAX is now defined to be 255 so that linux will eventually handle filesystems with longer names than 14 chars. This means that the old direntry-routines in the library won't compile correctly, as they depended on NAME_MAX being the size of a directory name. I hope the gcc-2 library won't have this problem, and that we can move over to the more general readdir-function without undue growing pains. The a.out.h change was made just to minimize the differences between the linux headers and the library headers - but the second change is pretty fundamental. If you are porting software with the old libraries, I'd suggest keeping to the old limits.h in /usr/include - that way nothing should break until we get non-minix filesystems. Adventurous people might want to test out the new kernel functions that will be supported even with new filesystems. In case anyone is wondering why the NAME_MAX change is needed, it's due to the fact that the old /library/ readdir only handled a 14-char library entry. When the VFS code is enhanced to allow different filesystems, you no longer can depend on this, and the library routine wouldn't know what type of directory it's supposed to read - so the code has to be moved into the kernel which knows about these things. The new readdir() will work correctly independently of the underlying filesystem (so that you can freely mix different filesystems without needing to bother about it). I'm sorry all this is certain to cause it's share of confusion (using the old library with the new NAME_MAX and vice versa), but there wasn't any graceful way to handle it all - unless I would have anticipated these problems from the start, which I didn't... You can console yourselves with the thought that linux should be able to handle longer filenames and >64MB partitions within a couple of releases. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: linux-0.95c known bugs Summary: well, it was alpha... Message-ID: <1992Apr8.090321.7673@klaava.Helsinki.FI> Date: 8 Apr 92 09:03:21 GMT Organization: University of Helsinki Lines: 58 Well, only one known bug so far, but a couple of problems. I thought I'd mention them before anyone else does, and we'll call them "features" :^) The BUG: when using the readdir() system call, linux incorrectly doesn't let go of the last buffer used for reading: this results in the buffer being marked as used (and if you use readdir() heavily, the counter will eventually wrap around, which might result in incorrect marking as "not used"). This bug happily isn't easy to find: no current binary uses the readdir() system call unless you have gotten your hands on the new VFS gcc-2.1 release. Thanks to Remy Card for finding this one. Not too bad a bug though: the fix is very easy. Add a 'brelse(bh);' in the minix_readdir() function, like this: if (i) { put_fs_long(de->inode,&dirent->d_ino); put_fs_byte(0,i+dirent->d_name); put_fs_word(i,&dirent->d_reclen); return i; should really be : if (i) { put_fs_long(de->inode,&dirent->d_ino); put_fs_byte(0,i+dirent->d_name); put_fs_word(i,&dirent->d_reclen); + brelse (bh); return i; That is, just add the brelse before the early return. Sorry for the lack of real cdiffs - I'm not at home right now, and the above was taken directly from the bug-report mail. The problems: I've had one report that the floppy-driver in versions 0.95x breaks when accessing drive nr 2. It doesn't on my machine, but I'd appreciate it if people would test it out, and mail me about any problems. So far, only one report, but that's one too many. 0.95c doesn't correctly keep track of the 'rss' field in the task-structure. A fix was already posted (and nothing breaks even if you don't apply the fix - ps just gives slightly incorrect output) And the expected troubles with the change of 'a.out.h' - the old gdb doesn't recognize new executables etc. As soon as I get my own sources cleaned up, I'll send out a new binary for the 0.95c+ kernel to the ftp-sites. I've gotten a few mails from people unable to recompile everything - either because of lack of diskspace or some other problem. Tomorrow I'll put the new kernel image on nic.funet.fi and tsx-11 - it's basically the 0.95c kernel + the above bugfix + the lp-patches (somewhat edited by me). Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux,alt.os.linux Subject: Re: Large disk partition Message-ID: <1992Apr8.122049.20594@klaava.Helsinki.FI> Date: 8 Apr 92 12:20:49 GMT References: <1992Apr7.202208.12193@spuddy.uucp> Organization: University of Helsinki Lines: 40 In article <1992Apr7.202208.12193@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes: >Is it possible for Linux to use a disk partition greater than 64Mb ? >I have a 650Mb disk at 1283x16x63. DOS takes up the first 1023 clinders >(the most it can have), leaving me 128Mb as a second partition. But when I >try mkfs it moans for greater than 64Mb :-( Yes, the 64MB limit is still there in the filesystem: it seems the VFS functions start to get complete soon, but I haven't written any actual code for any other fs-type. I'll be adding an "extended-minix" type soon - it will conform to the native-order-long minix filesystem type, which allows bigger disks, but still has the 14-character name limit (in case someone wonders why keep to minix types: it's easy to add, as I can use most of the old routines anyway, and some misguided persons use linux and minix side by side :) >Alternatively, could I make this into an extended partiton, with 2x64Mb >in that, or even 1x10Mb (root+tmp), 1x12Mb(swap=3xRAM),1x64 (/usr), 1x42 (think >of something!). As you report you have 0.95c running, it should be safe to use extended partitions, but the old fdisk probably has problems with them still. At least I haven't heard any reports of problems with extended partitions yet, although I haven't heard any success-stories either. There are other fdisks than the linux or dos ones - pfdisk etc is reported to work. I haven't got any personal experience (I should be so lucky to have the 1024-cylinder problem :). Anyway, linux 0.95c should report any partitions it finds at bootup (along with some data on size and position), and you should check the numbers before using extended partitions the first time. If the bootup-information seems to be ok, try out the extended partitions (but back up just in case...). >Help please! I am on 0.95c (yippeee! I successfully managed to get Linus's >patches to work! Well the kernel boots :-) ). Is everybody this surprised when one of my patches happen to work? :^) Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Job Ctrl && $$->programmers (How?) Keywords: jobs, money, bash, happy Message-ID: <1992Apr9.144903.19540@klaava.Helsinki.FI> Date: 9 Apr 92 14:49:03 GMT References: <83443@bu.edu> Organization: University of Helsinki Lines: 73 In article <83443@bu.edu> buckley@csa.UUCP (David Buckley) writes: > > Is there some version of jsh, or some implementation of the >functions fg, bg, %[n] etc... I didn't find them on the version of >bash I am using. Are there several versions of bash? How do we get >access to job ctrl? I know these exist from reading previous >postings, are they hiding or should I chmod u+rwx mybrain.out? Yes, there are several versions of bash existing - some of them are /very/ old. I don't know if the original bash.Z is still somehwre to be found, but it was not too long ago, and that is the version I used under 0.01, long before linux had job control. That version certainly doesn't support job control. Versions of bash that support job control (including the builtins fg, bg, kill, jobs etc) are available on older root-disks, notably the 0.95 (not "a") rootdisk. I don't know where to find a "standalone" version of bash - I know somebody ported bash 1.12 (the one on the rootdisk is 1.11 patch-level 1, although I think "help" returns 0.00.1). You might want to check out the abc-release when it gets out - right now the binaries under linux are a major mess (different versions under the same name etc...), but this will eventually be sorted out, I hope. > Also, is there some list of developers-port|ers so that >it might be easyer to direct financial contributions to this venture? >I haven't seen any postings with regards to how and to who money >should be donated, and I think it would be interesting to be able >to direct donations for specific implementations (our unix favourites), >beyond Linux itself. Such a posting (I feel) would be greately >appreciated. I have never felt anybody needed to pay for linux - I didn't want to make it share-ware, and I never wanted to make it commercial. The biggest reason I started on linux at all was that I had no good unix and no money - I wanted a totally free unix (not "GNU-free", but "no-money" free - the "GNU-free" came later). I still have no money, but at least I've got the unix :) In fact, the earliest copyrights expressly forbid /any/ money at all changing hands due to linux - the above was the reason. As the system actually became useable, I had to change my mind - I don't mind people making money off linux, as long as it essentially is available for free as well, which it is. I still feel strongly about the money-thing though - I don't want to encumber the "official" version with any kind of pleas for money. If I had something like "if you enjoy this package, please send $10 to xxx" it might scare away people from then sending other feedback (bugreports etc), as they didn't send the money... As it is, linux has no special "registered users" which get special treatment by me - if you are porting something important, I might give your troubles more thought than the average user, but I try to answer every problem that gets reported (even if it's just a "sorry, can't help this one" or "it's a known problem, I don't know the cure", "hardware dependant"). One thing I would appreciate is people sending me postcards from all over the world: I don't want to be a new Craig Shergold, but it might be fun to see where linux is used :^). Postcards (with least name and location written in for reference) could be sent to: Linus Torvalds Pietarinkatu 2 A 2 00140 Helsinki Finland and maybe I'll wallpaper my room with them :). Or maybe not. Linus PS. If you have contacts with hardware suppliers, and would like to get things like multi-serial cards/tape streamers etc supported... I just might be persuaded to try it out :-) ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Another bug? Message-ID: <1992Apr10.203916.27326@klaava.Helsinki.FI> Date: 10 Apr 92 20:39:16 GMT References: <1992Apr8.090321.7673@klaava.Helsinki.FI> <1992Apr9.200244.28901@wam.umd.edu> Organization: University of Helsinki Lines: 24 In article <1992Apr9.200244.28901@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes: >In article <1992Apr8.090321.7673@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: >>Well, only one known bug so far, but a couple of problems. I thought I'd >>mention them before anyone else does, and we'll call them "features" :^) > >More than once, I've gotten a message about mis-linked processes. I >usually get it when I'm compiling from one VC and using Kermit >interactively on another, but most of the time I'm compiling and using >Kermit.... The mis-linked process problem seems to be linked with swapping: I've never seen it, and most (all?) that have reported it have only 2M ram - it seems to be a race-condition in the exit code, that breaks while swapping heavily. I think that running gcc and kermit on a 2M system should be enough to swap quite a bit... I have fixed some of the exit-code in 0.95c+ - I'd be very interested to hear if this problem is gone with the new kernel. The exit-code was "interesting" - I think tytso optimized the sibling linking a bit too much, and it broke when paging meant that the kernel sleeps in some new circumstances. I might be totally off base - apologies to tytso if I am. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: kernel building problems Message-ID: <1992Apr11.095724.8928@klaava.Helsinki.FI> Date: 11 Apr 92 09:57:24 GMT References: <1992Apr10.153857.28399@CSD-NewsHost.Stanford.EDU> <1992Apr10.162906.21379@ods.com> Organization: University of Helsinki Lines: 20 In article <1992Apr10.162906.21379@ods.com> david@ods.com (David Engel) writes: > >Aside to Linus: Would you mind describing how you have your system set >up? It might help aleviate problems like this if we knew which compiler >and system libraries you are using. I'm still using 2.0 (and an older version at that) as I've been too busy to upgrade. I doubt the HJ-patch is really needed - I read through it, and I'd guess 0.95c+ should compile pretty cleanly without it. Anybody tried it? HJ's patch also assumes you have a 387, and you'll have to edit the makefile if you don't. I'll have to upgrade my compiler (probably this weekend), and the next real version should have no problems with 2.1. I'm in fact still using my original 1.40 for everything but the kernel - I've left the actual beta-testing of the new compilers and libraries to everyone else, and I'll step in now that they seem stable. Lazyness or prudency, you decide :) Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux,alt.os.linux Subject: Re: more on my problem(I still haven't got any help) : ) Message-ID: <1992Apr17.080304.20001@klaava.Helsinki.FI> Date: 17 Apr 92 08:03:04 GMT References: <1992Apr15.232024.23565@athena.mit.edu> Organization: University of Helsinki Lines: 21 In article <1992Apr15.232024.23565@athena.mit.edu> jgifford@attmail.com writes: >Ok, here goes: >I had xcomm, it was running fine. suddenly, it started outputting to the >screen 2 cr/lf for every one I hit on the keyboard. I went into kermit >to see if it was xcomm, or the place I am calling. kermit was doing >this: >C-Kermit>set line /dev/ttys4 > >C-kermit> set speed 2400 At least the double-spacing in kermit is due to login first enabling ECHONL on the tty for the password recognition (it naturally wants no echo on normal characters, but wants the newline to be echoed), and it doesn't disable it afterwards. This doesn't result in any problems for most things, but some programs (at least my port of kermit) seem not to notice it: kermit disables echoing, but doesn't disable the ECHONL. The cure for kermit is to write "stty -echonl" in your .profile or similar - I don't know if this helps xcomm as well. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 850 gig extended*2 partition on 300 meg drive? ;-) Message-ID: <1992Apr20.055129.21246@klaava.Helsinki.FI> Date: 20 Apr 92 05:51:29 GMT References: Organization: University of Helsinki Lines: 18 In article xtifr@netcom.com (Chris Waters) writes: > >Truly inconsequential, but I thought y'all might find this amusing. I >just tried the .95c+ bootimage out at tsx-11 (I had been using .95a), >and all of a sudden I get the following report from fdisk: [ "somewhat" erraneous output deleted ] The old fdisk messes up extended partitions (as did the old kernel), and shouldn't be used. Not that it does any harm, as the old fdisk only reads from the disk, but as you saw, it doesn't exactly give good results. With 0.95c+, the available partitions are reported at bootup, so the need for a fdisk is less, but I hope the next release will contain one that works correctly. Linus ================================ ================================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: gdb still isn't working Message-ID: <1992Apr20.085143.23027@klaava.Helsinki.FI> Date: 20 Apr 92 08:51:43 GMT References: Organization: University of Helsinki Lines: 35 In article hedrick@dumas.rutgers.edu (Charles Hedrick) writes: >I've been trying to get gdb working. The problem is more subtle than >I had first thought. It worked fine up to 0.95b. However as of 0.95c >and 0.95c+, it stopped working. Yes, it's a bug in the kernel. It was there already in 0.95b and earlier, but those had a (buggy) workaround that made it work for most things anyway. The problem was that not all kernel mode -> user mode changes checked the error conditions, so things like breakpoints didn't work too well. My personal version handles this correctly (as well as doing some other things in a cleaner manner), but I'm not quite ready for a new release yet. I could make YAAR (yet another alpha-release) or just mail interested parties the fixes needed - mail me if you're interested, and depending on the number of messages I get I'll make it a new release. Here's a preview of 0.96 (* means already implemented): * truncate/ftruncate/fchmod/fchown system calls * io-bitmap allowing user processes controlled access to io-ports (thanks to obz - needed for X) * mmap for /dev/mem - (thanks to obz) allows X etc to use the frame buffers * the signal-handling fixes needed for gdb - multiple shared libraries (pmacdona) - cleaned up special files: partly implemented already and probably some other minor fixes. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux,alt.os.linux Subject: pre-0.96 (was Re: gdb still isn't working) Message-ID: <1992Apr21.231510.5903@klaava.Helsinki.FI> Date: 21 Apr 92 23:15:10 GMT References: <1992Apr20.085143.23027@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 128 In article <1992Apr20.085143.23027@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: > [ trace not working in gdb ] > >My personal version handles this correctly (as well as doing some other >things in a cleaner manner), but I'm not quite ready for a new release >yet. I could make YAAR (yet another alpha-release) or just mail >interested parties the fixes needed - mail me if you're interested, and >depending on the number of messages I get I'll make it a new release. Ok, the response seems to make a new pre-release appropriate: I have uploaded "pre-0.96.tar.Z" to tsx-11 and nic. Here is what the pre-release contains: - truncate/ftruncate/fchmod/fchown system calls note that there aren't any library functions for these, so they aren't very useful yet... [f]truncate needed a change in the logic of the internal truncate VFS call - anybody that has any nonstandard filesystem probably needs to look it up. - io-bitmap syscalls giving root-processes access to selected io ports from user space. There is a "ioperm()" system call that lets the process select which ports it wants to enable/disable (all ports disabled as default) as well as a (standard sysv?) ioctl interface that X uses. again, no library stubs, but it allows things like reading and setting the cmos clock without using /dev/port, as well as control over the VGA registers... - mmap for /dev/mem more things needed for X... - the signal-handling fixes needed for gdb These aren't yet complete: serial lines still send signals under interrupts that can result in problems (ie ptrace doesn't correctly get them), but that's pretty unlikely (and will be fixed in the final 0.96). Breakpoints should work etc.. - multiple shared libraries Up to 6 simultaneous shared libraries/process: the patches were originally by pmacdona, but they were heavily changed by me, and I think they work in a more natural manner now. One user-level change is that the libraries are now checked for read and execute permissions for safety-reasons. - cleaned up special files. read/write/ioctl no longer has special-case code: it is all handled with tables to functions. This will mean that the SCSI patches won't patch in quite cleanly into 0.96: you'll need to add the code that sets up the functions. Again: device drivers and vfs-filesystem hackers need to look into the changes, although they are pretty logical (earlier versions just didn't implement all the vfs-routines) Note that the vfs-code for select is still not used: select is hardcoded for the devices it supports right now. - ptrace() has a new interface as gdb for versions < 0.95c don't work on the new version, and gdb won't work very well at all on 0.95c[+], there was no reason not to break ptrace. Thus 0.96 has a new calling convention for ptrace, and the old ptrace library function no longer works. I'm including the new ptrace library function at the end of this post. - mount() takes 4 arguments, and checks that only the super-user can mount/umount things. Happily this shouldn't break any old binaries. - some general cleanups I've made the pre-release available only as pure source code: no diffs, no binary. The reason is that most people that needed this release want it for the gdb-fixes: and they should have no problem recompiling the kernel. Others just have to wait for the real 0.96. Changes that are NOT in this pre-release, but which I hope to have in the real 0.96: - more include-file cleanups - I'm still working on these - the wd8003 driver and hopefully some other parts of biro's config. - select() using the vfs-tables. And possibly bugfixes that people find in this pre-release... Linus ---------- library ptrace.c (wants gcc-2.1) ---------- #define __LIBRARY__ #include #include int ptrace(int request, int pid, int addr, int data) { long ret; long res; if (request > 0 && request < 4) (long *)data = &ret; __asm__ volatile ("int $0x80" :"=a" (res) :"0" (__NR_ptrace),"b" (request), "c" (pid), "d" (addr), "S" (data) : "si","bx","cx","dx"); if (res >= 0) { if (request > 0 && request < 4) { errno = 0; return (ret); } return (int) res; } errno = -res; return -1; } ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: How to pronounce "Linux"? Message-ID: <1992Apr23.123216.22024@klaava.Helsinki.FI> Date: 23 Apr 92 12:32:16 GMT References: <1992Apr23.044317.3916@nuscc.nus.sg> Organization: University of Helsinki Lines: 25 In article <1992Apr23.044317.3916@nuscc.nus.sg> npngps@solomon.technet.sg (Ng Pheng Siong) writes: >I apologize if this is considered trivial, but what is the >proper pronunciation for "Linux"? > >Li lee or lie? >Nux nuks or nerks? Nooks? Oh god. We just hashed this through on alt.os.linux. It /definitely/ needs to go into the FAQ. 'li' is pronounced with a short [ee] sound: compare prInt, mInImal etc. 'nux' is also short, non-diphtong, like in pUt. It's partly due to minix: linux was just my working name for the thing, and as I wrote it to replace minix on my system, the result is what it is... linus' minix became linux. I originally intended it to be called freax (although buggix was one contender after I got fed up with some of the more persistent bugs :) and I think the kernel makefiles up to version 0.11 had something to that effect ("Makefile for the freax kernel" in a comment). But arl called the linux directory at nic.funet.fi pub/OS/Linux, and the name stuck. Maybe just as well: freax doesn't sound too good either (freax is obviosly free + freak + the obligatory -x). Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: gdb fails on ioctl?? Keywords: gdb ioctl Message-ID: <1992Apr24.215331.16846@klaava.Helsinki.FI> Date: 24 Apr 92 21:53:31 GMT References: <1992Apr24.085616.29705@cbnewsd.cb.att.com> <1992Apr24.163555.26570@watson.ibm.com> Organization: University of Helsinki Lines: 27 In article <1992Apr24.163555.26570@watson.ibm.com> rajat@watson.ibm.com (Rajat Datta) writes: >I'm getting the same problem. It's related to the under debugging >process doing a read from the tty. I guess gdb is doing TIOCSPGRP to >set the tty process group to be the same as the process under debug to >avoid the stopped input message, but the tty ioctl code is rejecting >it because the current process (gdb) does not have the same process >group as the one we're setting the tty to (the under debug process). Right. The easy fix if to comment out the session testing in tty_ioctl.c: right after the "case TIOCSPGRP:" comment out the two lines if (session_of_pgrp(pgrp) != current->session) return -EPERM; and gdb should be happy. The session_of_pgrp() code has problems (I think I've fixed them now, though). >I would appreciate a solution. Except for this, gdb works fine under >95c++ and is an indispensable tool. My version already has this fixed (not the above quick hack - another not-quite-as-ugly hack that might even be correct), and the real 0.96 (out next week? maybe) won't have the above problems. In the meantime, just dike out the two lines. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: swapfile on scsi? Keywords: does it work? Message-ID: <1992Apr25.182734.6720@klaava.Helsinki.FI> Date: 25 Apr 92 18:27:34 GMT References: <55716@hydra.gatech.EDU> Organization: University of Helsinki Lines: 22 [ swapon problems ] Ok, I thought I'd mentions this here, as I seem not to have done it in the readme's. After doing a "mkswap", it's best to sync the filesystem: swapping doesn't use the buffer cache, so before doing a swapon you should make sure the swap-space signature and ID bitmaps are correctly flushed out to the disk. Note that the above shouldn't result in any filesystem problems even if you don't sync: the block numbers are still gotten through the filesystem routines. It's just the data blocks themselves that are loaded with no regard for buffer cache coherency, as it makes little sense to keep swap data in the buffer cache. This is normally no problem, but for the fact that the first page (4 blocks) of the swapfile contains the signature, and is loaded with the normal swap-routines. The result is that if you see "swap space signature not found" or similar errors, it might be a good idea to sync, wait a bit for it to complete, and then try swapon again. Swapon should probably do an implicit sync, but I didn't think of it when I wrote it. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: My pre-0.96 won't run shared binaries Message-ID: <1992Apr27.083131.23100@klaava.Helsinki.FI> Date: 27 Apr 92 08:31:31 GMT References: Distribution: comp Organization: University of Helsinki Lines: 22 In article jes@mbio.med.upenn.edu (Joe Smith) writes: > >Well, I'm straight now on the ps patches, but it seems I was wrong >about pre-0.96 running ok: even a clean kernel refuses to run >shared-lib binaries, even 'hello.c', for a non-root user. They all >die with an 'invalid operand... segmentation fault'. Ok, if it works for root, the problem is probably the permissions for the shared library: check that /lib/libXXXX is both readable and executable by the user (and if you have a symlink, check that the file it points to is read/executable) Earlier versions didn't check for read/exec permissions, which is an obvious security problem: under 0.95c+ and earlier, you could effectively do a "uselib(XXXX)", and be able to read the file XXXX (except for the 1024 first bytes) by reading memory at 0x03c00000- in your process space. 0.96 (even the pre-version) checks the header of the file, and the permissions, to make sure you are trying to use a real library file that you have access to, so that this kind of thing wouldn't be possible. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: are raw floppy blocks kept in the buffer pool? Message-ID: <1992Apr29.064505.23303@klaava.Helsinki.FI> Date: 29 Apr 92 06:45:05 GMT References: Distribution: comp Organization: University of Helsinki Lines: 21 In article jes@mbio.med.upenn.edu (Joe Smith) writes: > >I was using tar to attempt a backup last night & noticed that after >tar finished and I removed the floppy, the drive light came back on >(of course that means the Linux is OTL until you put a floppy back in >the drive, and I have no idea whether it was reading or writing). It >made me wonder whether blocks written to a raw floppy device are >buffered by the kernel and if so, whether this is a ``good thing''. Yes, the raw devices are implemented on top of the buffer cache: a close() does an automatic sync. It's not standard, but it was easy to implement. It might be the reason why tar doesn't like to use multiple-disk backups on linux: although if you close the device and open it again at a disk-change there should be no problem. Does tar do this or just a lseek(0)? Linus PS. A simple fix is to do a "ll_rw_block(WRITE,bh)" in the block-device write function: I just did it, so 0.96 won't keep dirty blocks around at all. Reading still uses the buffer cache, though. ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Offical windows Message-ID: <1992Apr29.091015.27476@klaava.Helsinki.FI> Date: 29 Apr 92 09:10:15 GMT References: <08VwJB5w161w@grafted.UUCP> <4992@umriscc.isc.umr.edu> <1992Apr29.070932.25201@mnemosyne.cs.du.edu> Organization: University of Helsinki Lines: 34 In article <1992Apr29.070932.25201@mnemosyne.cs.du.edu> zmbenhal@isis.cs.du.edu (Zeyd M. Ben-Halim) writes: > >Well, linus has just said on comp.os.minix that X WORKS but is not to be >released to the "masses" yet! Don't take it too hard: I'm also part of "masses" - I haven't seen it working on my own machine yet... obz has been porting it for a longish time (started with the advent of 0.12 I think), and I don't know how many problems still remain (not too long ago he still had trouble returning to character mode after X exited etc). He's sent me mail that he edited in an xterm under linux though, so it's getting there... Some of the results are already visible in the pre-0.96 release: the mmap code and the io-port control needed for it. The socket code is still not ready: the socket-emulation library on top of pty's had problems, as the pty's aren't complete (they don't support hanging up etc yet). >The question is WHY NOT? Even if it is not working properly, couldn't we at >least hear about the effort involved in porting X (setting modes, reading, >writing to the screen memory, switching banks, etc.) I assume obz is nearing completion and alpha-testing: he created a X11 channel on the original mailing list. Not that there has been any activity yet :-) I also assume one reason we haven't heard too much about graphics under linux is simply because X11r5 (with the free X386 server) does all the mode-setting things by itself, and doesn't need the kernel to do that much. So porting X doesn't help other graphical systems that much: it's mainly a question of getting the same kind of support as "normal" 386-unixes allow X, ie mmap/sockets etc. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: alt.os.linux,comp.os.linux Subject: Re: Disk drive performance Message-ID: <1992Apr29.091828.27784@klaava.Helsinki.FI> Date: 29 Apr 92 09:18:28 GMT References: <1992Apr28.220324.25222@spuddy.uucp> Organization: University of Helsinki Lines: 15 Ok, as several people have written about bad IO performance, I decided to finally do some of the simplest optimizations possible under linux, so 0.96 will be a bit snappier when copying large files etc. Under very extreme circumstances, IO speeds are now 10 times faster according to my simple tests, but that's just "marketing info": most things are still about the same speed. None of the optimizations are in the driver proper: I just finally implemented read-ahead on files, and used the ps-patch that gives IO bound processes more time. Thus the speed-increase is most noticeable when you do something else in the background. I also changed sync a bit so that it doesn't wait around quite so much. Expect a slightly more responsive system, but no major changes. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Latin-1 again Message-ID: <1992Apr30.075826.7201@klaava.Helsinki.FI> Date: 30 Apr 92 07:58:26 GMT References: <1992Apr23.205017.6569@casbah.acns.nwu.edu> Organization: University of Helsinki Lines: 19 In article jem@niksula.hut.fi (Johan Myreen) writes: > >A while ago I posted patches to the keyboard driver so it could >produce Latin-1 characters. I never uploaded the patches, and they >don't work with current versions anyway. I'll dig them up and see what >needs to be done for the current version. I actually used the patches to some degree: I didn't use the keyboard patches, but I used the console-part, so linux pre-0.96 tries to do 8-bit latin1 printing. To some degree. I haven't tested it, as I don't have anything that uses the 8-bit characters, but it does seem to print out most of the correct characters. Try something like $ echo -e "\241" and you should get a inverted "!". It might even have been in 0.95c+, I dunno. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.96 out next week Message-ID: <1992May4.073803.3222@klaava.Helsinki.FI> Date: 4 May 92 07:38:03 GMT References: <1992May4.055329.17266@mnemosyne.cs.du.edu> Organization: University of Helsinki Lines: 61 Ok, the subject says most of it: I'll send out 0.96 sometimes next week (ie 92.05.11-17), and this is just an announcement to confirm that. 0.96 has a lot of changes (even relative to pre-0.96), and it's entirely possible that making it available as cdiffs isn't feasible. It contains a lot of new files, as well as some re-organizations in the old ones. Main new things are: - The SCSI distribution is now in the standard package. I (obviously) haven't been able to test my patchings, so there might be problems in this first release. I had to do some changes "blind" to the cdiffs, but most of them were pretty trivial. - X11r5 as ported by obz is supported. It's still in beta-testing (join the X11-channel on the original mailing-list), but as I'm writing this from an xterm under linux, it works pretty well. Changes to pre-0.96 are just the socket-code by obz, and some small tweaking by me. - Hopefully better interrupt latency - I've changed select() not to use cli-sti, and most IRQ's to enable interrupts, and instead disable just their own interrupt-line. The interrupt latency has been noticeable at higher serial speeds, and I hope 0.96 will be better in this respect. Again, I only have 2400bps, so I've never seen the problems, and cannot guarantee the new version will help. (btw, I hope the problems with select are gone now) - Reorganisation of the vfs routines and minix filesystem driver. These shouldn't bother anyone but people that have implemented their own filesystems (I know of just 2 to date), but I hope the current vfs-interface will prove to be relatively stable. The new vfs interface has made some things much cleaner, and the promised cleanup of special devices has happened. - ps/uptime patches + added readahead, so having computationally intensive background processes isn't as noticeable any more when doing IO. Additionally, there /might/ be a new floppy-driver that supports formatting and autodetecting floppies, but I haven't had time to check into it yet. There are probably any number of minor changes: I've lost track. People have sent me some diffs, and some of them went in, depending on how energetic I was that day. I've tried to correct all the bugs I've gotten reports on, and hopefully 0.96 will work with just about everything (gdb etc). Things I wanted, but didn't have time for: - The config patches aren't there. Sorry everybody. That means still no wd8003 driver etc. - Any number of minor patches (quota, auto-SVGA etc) Generally, 0.96 is cleaning some things up, but on the other hand the new features can have their share of problems. We'll see. Anyway, most things seem to work, and I hope there won't be the same type of problems as with the first 0.95 release. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: X386 (Was Re: 0.96 out next week) Message-ID: <1992May5.063513.11484@klaava.Helsinki.FI> Date: 5 May 92 06:35:13 GMT References: <1992May4.055329.17266@mnemosyne.cs.du.edu> <1992May4.073803.3222@klaava.Helsinki.FI> <1992May5.00552.26728@ms.uky.edu> Organization: University of Helsinki Lines: 28 In article <1992May5.00552.26728@ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes: >> [ X window system ] > >Here's a question. What CGA cards does it support, and at what >resolutions. Also, what's the realistic RAM requirements? X definitely won't work with CGA - it won't even work with normal VGA cards: you need SVGA (and even not just any SVGA card will do). The supported cards are et[3|4]000 and some others (pvga? tvga?). Resolutions range from 640x480 to 1192x900 (or something like that), all at 256 colours, depending on what kind of card/monitor combination you have. As to memory: I'm using it in 8MB ram, and no swapping (with a couple of xterms, xclock and xcalc - nothing major). If I want to recompile the kernel in an xterm, I'll have to start up swapping (well, actually I've done it without swapping, but it's tight). I assume it's still useable in 4MB and a big swap-file, but I'm happy I haven't tested it. Speed probably depends heavily on the SVGA card: on my 386/33 with a no-name et4000 card I get totally acceptable performance: scrolling big windows is slow with other things going on, but not irritatingly so. You don't want to make opaque moves, but I can live without that. Harddisk space is totally up to you: minimum about 10MB for just the minimal clients, maximum probably the sky is the limit. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Writing an OS - questions !! Message-ID: <1992May5.075817.15984@klaava.Helsinki.FI> Date: 5 May 92 07:58:17 GMT References: <10685@inews.intel.com> Organization: University of Helsinki Lines: 136 In article <10685@inews.intel.com> nani@td2cad.intel.com (V. Narayanan) writes: > >Hi folks, > For quite some time this "novice" has been wondering as to how one goes >about the task of writing an OS from "scratch". So here are some questions, >and I would appreciate if you could take time to answer 'em. Well, I see someone else already answered, but I thought I'd take on the linux-specific parts. Just my personal experiences, and I don't know how normal those are. >1) How would you typically debug the kernel during the development phase? Depends on both the machine and how far you have gotten on the kernel: on more simple systems it's generally easier to set up. Here's what I had to do on a 386 in protected mode. The worst part is starting off: after you have even a minimal system you can use printf etc, but moving to protected mode on a 386 isn't fun, especially if you at first don't know the architecture very well. It's distressingly easy to reboot the system at this stage: if the 386 notices something is wrong, it shuts down and reboots - you don't even get a chance to see what's wrong. Printf() isn't very useful - a reboot also clears the screen, and anyway, you have to have access to video-mem, which might fail if your segments are incorrect etc. Don't even think about debuggers: no debugger I know of can follow a 386 into protected mode. A 386 emulator might do the job, or some heavy hardware, but that isn't usually feasible. What I used was a simple killing-loop: I put in statements like die: jmp die at strategic places. If it locked up, you were ok, if it rebooted, you knew at least it happened before the die-loop. Alternatively, you might use the sound io ports for some sound-clues, but as I had no experience with PC hardware, I didn't even use that. I'm not saying this is the only way: I didn't start off to write a kernel, I just wanted to explore the 386 task-switching primitives etc, and that's how I started off (in about April-91). After you have a minimal system up and can use the screen for output, it gets a bit easier, but that's when you have to enable interrupts. Bang, instant reboot, and back to the old way. All in all, it took about 2 months for me to get all the 386 things pretty well sorted out so that I no longer had to count on avoiding rebooting at once, and having the basic things set up (paging, timer-interrupt and a simple task-switcher to test out the segments etc). >2) Can you test the kernel functionality by running it as a process on a > different OS? Wouldn't the OS(the development environment) generate > exceptions in cases when the kernel (of the new OS) tries to modify > 'priviledged' registers? Yes, it's generally possible for some things, but eg device drivers usually have to be tested out on the bare machine. I used minix to develop linux, so I had no access to IO registers, interrupts etc. Under DOS it would have been possible to get access to all these, but then you don't have 32-bit mode. Intel isn't that great - it would probably have been much easier on a 68040 or similar. So after getting a simple task-switcher (it switched between two processes that printed AAAA... and BBBB... respectively by using the timer-interrupt - Gods I was proud over that), I still had to continue debugging basically by using printf. The first thing written was the keyboard driver: that's the reason it's still written completely in assembler (I didn't dare move to C yet - I was still debugging at about instruction-level). After that I wrote the serial drivers, and voila, I had a simple terminal program running (well, not that simple actually). It was still the same two processes (AAA..), but now they read and wrote to the console/serial lines instead. I had to reboot to get out of it all, but it was a simple kernel. After that is was plain sailing: hairy coding still, but I had some devices, and debugging was easier. I started using C at this stage, and it certainly speeds up developement. This is also when I start to get serious about my megalomaniac ideas to make "a better minix that minix". I was hoping I'd be able to recompile gcc under linux some day... The harddisk driver was more of the same: this time the problems with bad documentation started to crop up. The PC may be the most used architecture in the world right now, but that doesn't mean the docs are any better: in fact I haven't seen /any/ book even mentioning the weird 386-387 coupling in an AT etc (Thanks Bruce). After that, a small filesystem, and voila, you have a minimal unix. Two months for basic setups, but then only slightly longer until I had a disk-driver (seriously buggy, but it happened to work on my machine) and a small filesystem. That was about when I made 0.01 available (late august-91? Something like that): it wasn't pretty, it had no floppy driver, and it couldn't do much anything. I don't think anybody ever compiled that version. But by then I was hooked, and didn't want to stop until I could chuck out minix. >3) Would new linkers and loaders have to be written before you get a basic > kernel running? All versions up to about 0.11 were crosscompiled under minix386 - as were the user programs. I got bash and gcc eventually working under 0.02, and while a race-condition in the buffer-cache code prevented me from recompiling gcc with itself, I was able to tackle smaller compiles. 0.03 (October?) was able to recompile gcc under itself, and I think that's the first version that anybody else actually used. Still no floppies, but most of the basic things worked. Afetr 0.03 I decided that the next version was actually useable (it was, kind of, but boy is X under 0.96 more impressive), and I called the next version 0.10 (November?). It still had a rather serious bug in the buffer-cache handling code, but after patching that, it was pretty ok. 0.11 (December) had the first floppy driver, and was the point where I started doing linux developement under itself. Quite as well, as I trashed my minix386 partition by mistake when trying to autodial /dev/hd2. By that time others were actually using linux, and running out of memory. Especially sad was the fact that gcc wouldn't work on a 2MB machine, and although c386 was ported, it didn't do everything gcc did, and couldn't recompile the kernel. So I had to implement disk-paging: 0.12 came out in January (?) and had paging by me as well as job control by tytso (and other patches: pmacdona had started on VC's etc). It was the first release that started to have "non-essential" features, and being partly written by others. It was also the first release that actually did many things better than minix, and by now people started to really get interested. Then it was 0.95 in March, bugfixes in April, and soon 0.96. It's certainly been fun (and I trust will continue to be so) - reactions have been mostly very positive, and you do learn a lot doing this type of thing (on the other hand, your studies suffer in other respects :) Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: What kernel needed to run X??? Message-ID: <1992May5.191103.4763@klaava.Helsinki.FI> Date: 5 May 92 19:11:03 GMT References: <13013@ucdavis.ucdavis.edu> Organization: University of Helsinki Lines: 9 In article <13013@ucdavis.ucdavis.edu> mayfield@toadflax.UCDavis.EDU (Doug Mayfield) writes: >To re-iterate... What version of the kernel is required to >run X. You need pre-0.96 with the (pretty small) patches for sockets that are included with the X distribution. Alternatively, you can wait a week for the real 0.96, which also fixes a couple of minor problems. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: X386 and lame SVGA cards Message-ID: <1992May6.220143.13536@klaava.Helsinki.FI> Date: 6 May 92 22:01:43 GMT References: <1992May6.151359@hammer.Prime.COM> Organization: University of Helsinki Lines: 36 In article <1992May6.151359@hammer.Prime.COM> cummings@hammer.Prime.COM (Kevin Cummings) and others write: > > [ no support for some cards, or even standard 640x480x16, as it's > > not "worth it" ] > >I don't agree with them, but they have the source, and I don't. Well, in fact you /do/ have source: just get the X11r5 distribution and hack on it. That's how the original X386 was created (well, it wasn't based on r5, but you get the idea). The linux X-server certainly isn't based on any proprietary code. There seem to be several drivers that implement standard VGA modes (just look at "real" unixes), but sadly, none of them seem to be freely distributable, and so aren't part of the standard distribution. The X386 drivers included are written by Roell, and it's not really fair to criticize him for not writing drivers for all the possible card combinations. He did them for free, after all (sadly (for us - I doubt he minds) he seems now to get paid for his effors, so he no longer makes them available for no chanrge). If you want to lay the blame somewhere, do it at IBM who didn't come up with a good standard for video cards. The reason there doesn't seem to exist any 16-colour drivers for free is simply because nobody seems to have wanted to write them: 16-colour programming isn't fun, and the results aren't as pleasing as 256 colour modes. Not surprisingly, 256 colour mode is more popular. Also, not surprisingly, chipsets that are easier to program (ie et4000) get the drivers. What I'm trying to say is that X386 is free, and that nobody got paid for producing it: don't be surprised if it doesn't support all hardware. Even as I'm not going to write a PS2 version of linux (unless somebody gives me a PS2 + docs etc), I assume roell didn't want to write a version that he felt was "uninteresting". Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: pre-0.96 & inaccessable memory as non-root Keywords: segmentation fault Message-ID: <1992May7.081436.25846@klaava.Helsinki.FI> Date: 7 May 92 08:14:36 GMT References: Organization: University of Helsinki Lines: 21 In article pfaffman@pilot.njin.net (Jay Pfaffman) writes: > >I installed the pre-0.96 release on two machines and have successfully >installed it on one of them. On the other, though, no one but root >can login. I played with changing UID, and found that the first >memory access after changing to something other than root I get a >segmentation fault. Have I done something stupid? It works fine on >another machine. (I'm using it now). Ok, this is probably the shared libraries that bite you: pre-0.96 added more sanity checks than earlier versions, and won't load in the shared libraries unless they are readable and executable by the user. Check that the shared libraries in /lib/libXX.YY.ZZ all have the correct permissions. Due to a bug in the early crt0.s, not being able to load the shared library results in a segmentation fault: this should be fixed in the newer gcc-2.1 versions, but programs compiled with the old ones will fail without any error-message. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Wow! X is great! Message-ID: <1992May7.174038.16552@klaava.Helsinki.FI> Date: 7 May 92 17:40:38 GMT References: Distribution: comp Organization: University of Helsinki Lines: 51 In article pnakada@oracle.com (Paul Nakada) writes: > >a serious bug. If I pull down the xterm middle menu (control + >middlebutton (both buttons)) my screen gets shifted ~30% with the >right side wrapping to the left side. wierd. Yes, this is one of the bugs that is still in the pre-0.96 release with the X patches: it's due to the fact that error messages get printed to the console, and the pre-0.96 kernel didn't notice that things were in graphics mode, so it prints out the message and changes various VGA regs, thinking it writes to a normal text-screen. This obviously doesn't work too well when in garphics mode. Other bugs relate to the pty's: when scrolling in an xterm it sometimes stops, and you have to hit a key to get it to wake up. I've also found it's possible to freeze the machine with ^C under some circumstances when writing heavily to pty's. Don't try it without syncing first, and avoid testing it at all if possible :) All the above bugs should be fixed in next weeks release, so I'm not making patches available right now. Additionally, 0.96 has the TIOCCONS ioctl that allows a pty to get the output intended for the console (so that you see whan processes write directly to /dev/tty0 etc), as well as a syslog() system call (syscall nr 103) that reads the messages printed with printk(). The syslog syscall means you can get the kernel warning messages to a window under X. Of course, the really bad messages (notably kernel panics) don't get printed, but hopefully those aren't that usual. TIOCCONS was easy to add due to the better vfs routines. Similarly, 0.96 now supports dropping DTR when a serial line is finally closed. Thank abc for goading me into adding the trivial fix. In an earlier post I mentioned that 0.96 might have a new floppy-driver: I just patched it in today, and it seems to work, so that's official. The new floppy-driver finally allows formatting, and also has auto-detect floppies (much nicer than under minix: they are quite as fast as the non-auto versions from my limited testing) as well as user-defined floppy-types (ie you can define 20-sector formats on the fly etc..). The patches were courtesy of Werner Almesberger, so send him a kind thought. >is libobz.a going to be part of the 0.96 release? it's missing from >the pre 96 + X patches release, making building any X apps impossible. Hlu has already added them to the library: the newest version should have them and some other syscalls ([f]truncate etc). I also think it now supports multiple shared libraries: practical for X and math. I haven't had time to try it out myself yet. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: fsck and inode Keywords: filesystem,inode Message-ID: <1992May8.055503.1211@klaava.Helsinki.FI> Date: 8 May 92 05:55:03 GMT References: Organization: University of Helsinki Lines: 30 In article rickw@fraser.sfu.ca (Rick Wong) writes: > >I am new to filesystems in unix, so please bear with me. > >when I ran the following command >fsck -m /dev/hda7 >I got these output > >inode 266 not cleared [ etc ] This is normal under linux: the "-m" flag stands for minix, and means fsck will do extra checking in the inode like the minix fsck does. The linux filesystem is almost completely the same as the minix one, but there are a few very minor differences. The main one is that linux doesn't clear the i_mode field of an inode that is no longer used, and minix does. The result is that if you use minix' fsck, it gives warnings of the above type after you have used linux for a while. Just so I could get the same warnings if I wanted, I added the '-m' switch - it's there but you aren't supposed to use it. This was mentioned in early readme's, when you actually had to use minix to set linux up, and people probably used the two systems side by side. Now I assume most people are running just one or the other, so I haven't even mentioned it in the readme's any more, as the feature no longer has any meaning. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Test-image of 0.96 available at banjo Summary: just the binary Message-ID: <1992May8.220544.832@klaava.Helsinki.FI> Date: 8 May 92 22:05:44 GMT Organization: University of Helsinki Lines: 37 As 0.96 has some changes in harddisk IO handling (interrupts, timings etc), I'd like for people that have ever had problems with the harddisk driver under linux to try out the last test-image of the 0.96 kernel before the official release - I'd rather not have the same types of problems that we had with 0.95. The image (no sources - wait till next week) is available at banjo.concert.net: pub/Linux/Incoming/testimage.Z, and is just my current bootimage that I'd like some feedback on. The changes to the harddisk driver (which is the main reason I want to make sure this version works) are just: - interrupts enabled most of the time - inb_p / outb_p changes The first one is to lessen interrupt latency, the second one hopefully helps people who had problems with the driver at high speeds. Both changes work well for me, but then my machine seems to accept almost anything... I hope 0.96 will work without any "a" releases. I'd also be interested to hear if this image removes the problems with serial lines at high speeds under X, as well as /any/ other problems. I can still make minor bug-fixes if something turns up, but I'd want reports by early next week or so (preferably with "testimage" in the subject line). The image is compiled with the us keyboard maps, and with the floppy-device as root. It should be binary compatible with all old versions, as well as the interim X version, so you just plug in the new kernel and you're (hopefully) off. Ignore this post if you don't have time to check out the image this weekend: the image is only meant as a quick test-release to get some fast feedback. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Sources (IMPORTANT to managers of LINUX ftp sites) Message-ID: <1992May11.083344.3440@klaava.Helsinki.FI> Date: 11 May 92 08:33:44 GMT References: <1992May9.165404.20041@leland.Stanford.EDU> <7!jkhpq.aclark@netcom.com> <1992May10.202916.26781@news.Hawaii.Edu> Organization: University of Helsinki Lines: 24 In article <1992May10.202916.26781@news.Hawaii.Edu> lee@uhunix.uhcc.Hawaii.Edu (Greg Lee) writes: > >Since we are so heavily indebted to fsf, it would make sense to think first >about what is courteous and much later about what we could get away with. Indeed. I hope people try to follow the /intent/ of the GPL first, and then start worrying about the legal implications. I don't feel too strongly about the legalese: it's there just because it's required to uphold that intent in a court of law, and wouldn't even be needed otherwise. I'd suggest not reading the GPL searching for loopholes - but on the other hand not being unnecessarily strict about it either. Use a bit of common sense in it all (until somebody starts threatening with legal action: but in that case you have probably not been following the GPL even in intent). There are probably quite a few binaries that should be removed from the linux archives: especially the older ones that needed a bit more porting than they need now with the better compiler/library, and that might not have source (I think my original gcc-1.40 and bash-1.05 should probably be removed: I've had to delete my sources to get X running.. Nobody uses them any more anyway). It might even result in some general cleanup of old binaries... Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: RTS/CTS flow control on serial ports Message-ID: <1992May11.184925.7185@klaava.Helsinki.FI> Date: 11 May 92 18:49:25 GMT References: <1992May10.101454.28203@colorado.edu> <57233@hydra.gatech.EDU> Organization: University of Helsinki Lines: 32 In article <57233@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes: >in article <1992May10.101454.28203@colorado.edu>, drew@romeo.cs.colorado.edu (Drew Eckhardt) says: > >> Linux pre-.96 or before does not support hard flow control. > >Will it ever? Well, I did some hacking this Sunday, and the serial driver is now completely rewritten in C - the file rs_io.s no longer exists. That also made it easy to implement hangup upon loosing carrier, so that too is now supported by the 0.96 kernel (which I'll probably send out tomorrow (Tuesday)). The rewrite in C is a pretty straightforward translation from the algorithm I used in assembler, but it should make things very much easier to change and understand for people not familiar with asm (and it's easier for me too, I have to admit). Even though flow control still isn't supported, I'd guess it's now just a matter of a few lines of C to get it into the kernel, so I expect I'll get patches for it eventually (or I'll implement it myself when I get bored enough). The rewrite might mean there are new bugs, and it certainly makes the interrupts a few instructions slower, but I hope performance won't suffer noticeably. And adding support for 16550 as well as for non-standard interrupts should be much easier now, even for people that aren't heavily into assembly. The only unnecessary assembler still found in the kernel is the keyboard driver: I expect I'll clean that up too in a not too distant future. That one won't be in 0.96, though. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: filesystems Message-ID: <1992May11.203853.9747@klaava.Helsinki.FI> Date: 11 May 92 20:38:53 GMT References: <1992May11.141929.25283@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 36 In article magnus@hsr.no writes: >I may be chewing an old bone here, but is 28 characters in a file name >really enough..? It's a lot better than what we have now, of course - >but why not go for the 256 at once? The reason I chose 30 (or 28) chars is that I don't want to move away from the fixed-length directory structure for the first "non-minix" vfs system I write: that way I can avoid some of the troubles, while still getting a reasonable system. Having a 256-char fixed-length directory structure is a bit too wasteful even for my taste. Why fixed-length? It's partly because it's slightly easier (not that it's that noticeable: I think the vfs routines will have no problem at all with variable-sized names), but mostly because it can be gotten almost for free with only minor tweaking of the current minix vfs-sources. Thus it will serve as an example of having different filesystems at the same time, while not actually adding very much code to the kernel. > Or does what you said imply that I >can make a few simple changes (additions) in the source and build my >own filesystem? I still would like 256 ch/filename to be a standard.. Yes, it should be pretty easy to change the sources to add a filesystem of your own with any filename length (255 chars max due to an arbitrary limit: I think that will be enough for everybody). It will be a lot easier when you have some examples, I think. Also, even if you made this change just on your own system, it isn't visible on a user level at all, except for the fact that you can create longer filenames of course. This means that you can run any binaries you want on the new filesystem, and as long as they have been compiled with the new gcc-2.1 that supports readdir(), they will work on any system, including your own specialized fs. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: ESDI drive compatibility Message-ID: <1992May11.141929.25283@klaava.Helsinki.FI> Date: 11 May 92 14:19:29 GMT References: <34836@darkstar.ucsc.edu> <1992May10.013723.7373@spuddy.uucp> Organization: University of Helsinki Lines: 31 In article magnus@hsr.no writes: >In article <1992May10.013723.7373@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes: > My next problem is when I plug in my SECOND disk (same size) I'll be forced > to have 10x64Mb partitions because of the current FS restrictions :-( > >Don't worry - the Minix file system is *not* here to stay. I just hope >it will be easy to transfer files from a minix fs to the new one. Will >you do 'mount x x [minix|vfs|msdos\..]' in 0.96..? Linus? 0.96 still won't have other filesystems than the old minix one, although I did get patches to implement longer names and long block-numbers. I'm pretty certain 0.97 will support 4GB disks and at least 28 character filenames: the vfs routines finally seem to be pretty logical and I no longer feel the urge to change a lot of things on that level any more. And yes, it will be very easy to move around different filesystems: you can mount them as any normal minix partition, and copy things around transparently. The only problem will be old binaries that still read directories directly: those won't be able to handle longer filenames. I assume that by the time 0.97 comes out, this won't be that much of a problem any more (assuming new versions at the same rate as before, 0.97 will be out by midsummer or so: I'll continue on linux during the summer). The idea behind the vfs routines is that all this can happen without any major trauma: people can go on using the old filesystem if they wish, or use several different types at the same time, mounting and umounting them as they see fit. I haven't done it myself, but I know the routines work, as others have tried it out. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.96 uploaded Summary: new release Message-ID: <1992May12.165112.24234@klaava.Helsinki.FI> Date: 12 May 92 16:51:12 GMT Organization: University of Helsinki Lines: 71 Well, the title says it all: I've sent off 0.96 to banjo.concert.net, where it can be found in pub/Linux/Linus along with a new bootimage and a program for formatting floppies under linux (which works only under 0.96). I've also sent it to tsx-11.mit.edu and I'll send it to nic as soon as the lines clear up. General warning about 0.96: - the scsi code is in the kernel, but I haven't personally tested it, so who knows... The SCSI code also results in a 4-5 second pause at bootup with the current bootimage, while it searches for an adapter: if you find this disturbing, you have to recompile the kernel with the appropriate changes to config.h. - The harddisk timings have changed: the testimage got a generally good review, but it hasn't been tested very much. The changes seem to help at least some "HD times out" problems, but there might be new bugs.. - The serial code was totally rewritten this weekend, and I haven't tested it out under any heavier load. I found one bug as late as today, and there might be others lurking around. - There have been generally pretty heavy rewrites: it's binary compatible with the old kernels, but the changes might not all be correct. Oh, well. That said, I hope 0.96 will be an improvement on earlier versions, and most of the old bugs corrected. If the new version still has some problem - please mail me with a new bugreport. Otherwise I'll just assume the problem went away: I'm afraid don't have time to go through old mail searching for any bugs that might still be in there. Partial list of features: - automatic floppy detection. Please add the following devices: mknod /dev/fd0 b 2 0 mknod /dev/fd1 b 2 1 which act as A and B floppies respectively, finding out automatically what kind of disk there is. The floppy driver now also contains a timeout, so an empty diskdrive no longer results in a floppy driver hang. - serial lines now support dropping DTR on closing, and sending SIGHUP to the process group that is logged in on a serial line. It's also a lot easier to change the interrupts etc of the lines. - unix sockets supported for X, as well as mmap() on /dev/mem etc. - pty's corrected. Hopefully no more hangs under X due to pty trouble. - better IO-performance when there are computationally intensive jobs in the background or on another VC. Partly due to new scheduler mechanism, partly due to read-ahead on normal files. - cleaned up vfs layer. - no more mismatched children - minor corrections all over the place. The new release is in fact different enough that there is no use trying to make context diffs: files have disappeared, others are new, others have simply changed a lot. Even compared to pre-0.96 there has been quite a lot of changes. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Testers wanted... new 0.96 image Message-ID: <1992May14.132345.12095@klaava.Helsinki.FI> Date: 14 May 92 13:23:45 GMT Organization: University of Helsinki Lines: 15 I've put a new testimage on banjo.concert.net: pub/Linux/Linus/boot92.05.14.Z and I hope people that have problems with 0.96 could try it out. I've mainly tried to remove some races in the serial code, but I hope this image also corrects the bootup problems experienced by some people. If you have problems booting the original 0.96, or are seeing more errors with the new serial lines, please try it out. As with the earlier testimage, it's no use to me if you can't test it out in a day or two: by that time I'll probably release 0.96a or a new testimage depending on the success of this one. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: pcomm95c Message-ID: <1992May17.112630.28674@klaava.Helsinki.FI> Date: 17 May 92 11:26:30 GMT References: <1992May16.035813.832@uniwa.uwa.edu.au> Organization: University of Helsinki Lines: 23 In article <1992May16.035813.832@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes: > >Hmmm. I have the same problem that the original poster had. i.e. haveing >type a few keys after control-A 0 before the help screen flashes, and >then it does just that, flashes. Looking deeping, I find that the time >is actaully spent in the kernel. Somehow (I couldn find it. ) it is >setting VMIN in the termios structure to be 4. so you have to type 4 >keys before the kernel will return on the read() call. > >Fixing this is a matter of finding where the VMIN feild is set. But the >original program has been hacked so badly, I put it aside for now.. This sounds like a problem I had with some version of kermit: some of the programs seem to have the c_cc offsets hardcoded into numbers instead of using VMIN/VEOF etc.. Very bad programming style, and I think it breaks under linux which doesn't have exactly the same c_cc offsets as most other unices it seems. Linux has distinct VEOF (4) and VMIN (6), while for example SunOS seems to use the same value (4) for both of these. I don't know if the latter is actually what posix specifies, but I doubt it. Can anybody confirm? Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: minix Message-ID: <1992May18.111600.26984@klaava.Helsinki.FI> Date: 18 May 92 11:16:00 GMT References: <1992May18.101044.26717@athena.mit.edu> Organization: University of Helsinki Lines: 50 In article <1992May18.101044.26717@athena.mit.edu> J.Jagger@sheffield-city-poly.ac.uk writes: >Hello, Linux newbee JJ here. I'm still waiting for a hard disk to >arrive in the post to install linux, so while I was waiting I thought >I'd have a quick read of Tanenbaums book 'Operating Systems, >Design and Implementation.' (This contains the source code to >MINIX). Two things. > >1. The source code for init and the shell are not included (in the >book). How different are the linux versions from the 'original' MINIX >versions? I get the feeling you think linux evolved from minix? This is not true: linux was written under minix, and while linux superficially resembles minix386, it's really not that close to minix in any way... The most minix-like feature in linux is the filesystem: due to practical reasons I wanted to have the same physical layout of the disk as in minix. Reading Tanenbaum is good for a general idea of operating systems, but it's generally not worth it to read the minix specific bits in order to understand linux (reading the minix source code in order to understand the genera idea might be worth it). While the filesystem has the same physical layout, multithreading means locking etc needs to be done totally differently etc. The kernel proper also uses totally different design ideals, and the device drivers are also very different (ie they use interrupts directly instead of waiting for hardware messages etc). Lastly, minix and linux memory management is fundamentally different: linux uses paging on a very low level for everything: minix uses a heap-like memory management strategy, I think. As to the shell under linux: there are several (although bash is the only one I use), and the same shells are generally available for minix as well (not standard PC-minix: it can't run tcsh/bash due to the 64kB limit). The standard minix shell isn't available for linux (not that big a loss: the minix shell doesn't do your mental sanity much good): ash is probably the closest thing. I don't know about /bin/init: I never looked at the sources under minix, and I haven't exactly dissected it under linux either. > [ Lions book ] >Is this booklet still available ? >If so does anyone know where I can get a copy of it ? I doubt you'll find a copy of the Lions book: I think the only way to get your hands on it would be to find somebody who did the course and photocopy it off him. I don't think AT&T allows that kind of thing any more, so it's probably illegal. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: gdb postmortem debugging... Message-ID: <1992May18.142534.6381@klaava.Helsinki.FI> Date: 18 May 92 14:25:34 GMT References: <1992May14.165106.8531@m.cs.uiuc.edu> <1992May18.123608.8795@fwi.uva.nl> Organization: University of Helsinki Lines: 15 In article <1992May18.123608.8795@fwi.uva.nl> lankeste@fwi.uva.nl (Branko Lankester) writes: > >You can replace do_exit(11) in die() in kernel/traps.c with >send_sig(SIGSEGV, current, 0), linux versions before 0.96 had >to use do_exit() because the old trap handlers didn't do signal >recognition. Yes, this will fix the problem, but it's not completely safe: if the error occurs in the kernel, it will probably lock up. Most of the errors occur in user space, but if syscalls are given bad arguments or similar you can induce general protection errors in kernel space: send_sig will not work in that case, while do_exit() always terminates the process cleanly (but doesn't work for gdb). Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Harddisk problems, new testrelease Message-ID: <1992May18.165317.11176@klaava.Helsinki.FI> Date: 18 May 92 16:53:17 GMT Organization: University of Helsinki Lines: 23 I've put out the latest test-image on banjo.concert.net in the file pub/Linux/Linus/boot92.05.18.Z: it should hopefully correct the harddisk problems some people have had with plain 0.96. I'll make it official by calling it 0.96a if there are no more problems (and make source available as well. Later this week). If you had fs corruption problems or similar with 0.96, try out the new version: unless I get feedback on it, I can't try to correct any remaining hardware-related bugs. It seems the harddisk interrupts have to run to completion with all other interrupts disabled: I haven't found out exactly where the problem is, but that's how it looks right now. Thus interrupt latency went up again :(. It's still better than 0.95, I hope. The above testimage (and the upcoming 0.96a release) contains the kill fix (and the same serial fixes as in the last testimage), and uses the rewritten keyboard handler by Johan Myreen (essentially the same driver, but rewritten in C). Linus PS. boot92.05.18.Z on saatavilla my|s klaavassa: /usr/tmp/linux =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: linux as only bootable partition Keywords: linux, boot, shoelace Message-ID: <1992May21.063838.3334@klaava.Helsinki.FI> Date: 21 May 92 06:38:38 GMT References: <1992May21.053756.13081@cs.ubc.ca> Organization: University of Helsinki Lines: 16 In article <1992May21.053756.13081@cs.ubc.ca> edmonds@cs.ubc.ca (Brian Edmonds) writes: [ just answering the PS - I don't have DOS, but I still boot from floppy just because I want to have several different kernel images... ] > >PS: when is 16550 support expected? I specificly ordered serial >ports with these, as the FIFO seems an especially elegant solution to >too many interrupts at high data rates. I'd love to support a 16550, but I don't have any data on it (and no chip). The optimal solution would be that somebody else writes the changes to the serial driver, but I can certainly try to do it blind if I could get docs. So if somebody has good technical dosumentation on the 16550 in machine-readable format, please mail it to me: I won't promise anything, but I might get it to work. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.96a out today/tomorrow Message-ID: <1992May21.121955.1485@klaava.Helsinki.FI> Date: 21 May 92 12:19:55 GMT Organization: University of Helsinki Lines: 49 The subject say it all: I haven't heard any bad results (except somewhat worse performance on the serial lines) from the testimage testers, so I'll make 0.96a available tonight (Finnish time: EST) or tomorrow. tsx-11, nic and banjo will be the sites I'll upload it to. 0.96a doesn't have any major new features: I just tried to correct known bugs and get a stable version out the door. I hope 0.96 won't need any more interim releases, but we'll see. 0.96a has gone back to non-interruptible hd-interrupts, and as long as I'm not sure about the reason for the need of this, it's going to stay that way. I hope this new version will run on all drives that have been supported in the past, and the only known remaining problem is the Kalok drives which have spurious interrupts. That's definitely a hardware problem, and Branko Lankaster has patches that fake away these.. 0.96a should also correct most of the serial line problems, and the keyboard driver is now in C - I expect somebody will change it to allow run-time keyboard changing. Additionally, there are various minor fixes in various places: - the kill fix by tytso that allows any process to wake up a stopped process as long as it's in the same session. - chown fix by card and me. Users can chgrp files they own to any group they belong to etc - _POSIX_CHOWN_RESTRICTED should now be implemented correctly. Also, chown() on a symlink now actually chown's the symlink and not the file it points to (but GNU fileutils don't seem to want to chown symlinks anyway - or maybe I have an older version) - SIGSEGV fix by lankaster (?) which allows for better debugging after protection faults. Most such errors are now trappable in gdb (although some circumstances can still result in the process exiting at once: out-of-memory errors etc) I have also changed the memory manager to check for illegal memory references (ie using the area between brk and stack), so debugging bad pointer references should be much easier. This fix will hopefully also trap the uncompress problem with bad files, but I haven't tried it out. Programs can still call brk() with any value, so it doesn't mean that you can't use up all available memory, but at least this should fix /bad/ memory references. My limited tests with gdb seems to indicate it all works nicely. Core files are still not generated (I haven't got the slightest idea what format they should have), so debugging isn't perfect yet, but it should certainly be much easier. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: VFS - Where can I read about it? Message-ID: <1992May22.050933.22701@klaava.Helsinki.FI> Date: 22 May 92 05:09:33 GMT References: Organization: University of Helsinki Lines: 49 In article lcd@ais.org (Leon Dent) writes: >I read comp.os.linux, but don't (can't) yet run it. The VFS concept >interests me, but I don't know what books or papers explain it. >Pointers anyone? As with the rest of the kernel internals, linux VFS doesn't exactly look like anything else: the ideas are the same as in SunOS etc, but the implementation is linux-specific (the first alpha-release used similar macros as SunOS I think, but after my rewrites...) So the only place to learn about linux VFS is the source code. It's not really that bad: it's pretty simple. The different routines are selected by following pointers to structures containg function-pointers. For example if you want to find out which inode the name "/usr" points to, you can use something like this (simplified, but you get the idea): ... dir = current->root; if (!dir->i_ops || !dir->i_ops->lookup) return -ENOTDIR; inode = dir->i_ops->lookup(dir,"usr"); ... Similarly, if you wanted to create the directory of "src/linux" relative to the current pwd, you'd use something like this: dir = current->pwd; if (!dir.... inode = dir->i_ops->lookup(dir,"src"); if (!inode || !inode->i_ops || !inode->i_ops->mkdir) return -ENOENT; return inode->i_ops->mkdir(inode,"linux"); (when I use a string in the above, the real routines actually use a pointer+length combination instead of the normal C strings. This means there is no need to copy names around: we use the name the user supplied directly, and the VFS routines parse away the slashes.. And as the pointers are relative to the %fs segment, we can choose user/kernel space strings just by changing the segment) So the VFS layer just translates the unix system calls to these kinds of indirect calls, keeping track of mount points/root/pwd etc. Thus the fs is effectively in two separate pieces: the VFS which parses complete filenames, and the filesystem-specific parts which just work on one part at a time. The VFS doesn't care about the disk layout, and the fs-specific parts don't have to know anything about mount-points/current root/pwd etc idiosyncracies. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: VFS - Where can I read about it? Message-ID: <1992May22.201941.13737@klaava.Helsinki.FI> Date: 22 May 92 20:19:41 GMT References: <1992May22.050933.22701@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 29 In article jes@mbio.med.upenn.edu (Joe Smith) writes: > >What happens with mkfs & fsck? Can these be written using standard >Unix system calls (through the VFS, and thus are indifferent to fs >changes), or will we need a separate executable (or switch) for each >fs? Are we still without source for fsck and if so, will the old one >work with a 30-char-filename fs? How about mount? mkfs/fsck will have to be written especially for each filesystem: these are purely user-level programs which operate directly on the block device. mkfs is usually very simple to write: the only thing needed is to set up an empty filesystem so that the kernel can then start operating on it and fill it with data, but fsck is a very complicated program, and getting it right is not easy (the current linux fsck is not very good, and does only a half-hearted job which isn't good enough in many situations) As to mount(), this is a kernel primitive, and is part of the filesystem drivers. Mount is given a extra parameter that indicates which type of filesystem to mount (the name of the filesystem type), and then "bootstraps" the filesystem information by filling in the appropriate inode operations for the root inode of the new filesystem etc. So to mount a DOS filesystem (if/when it is finally implemented), you'd use something like "mount /dev/hdb3 /local DOS". The current mount just gives a NULL for the filesystem name, which the kernel takes to be the default minix filesystem. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.96a available Message-ID: <1992May22.210159.14611@klaava.Helsinki.FI> Date: 22 May 92 21:01:59 GMT Organization: University of Helsinki Lines: 36 Oh, well, no use in delaying it any more, so I sent out my latest release to nic.funet.fi, tsx-11.mit.edu and banjo.concert.net. They should show up in the next couple of days (they are already visible on banjo: /pub/Linux/Linus). I hope all the bugs got fixed, but I did something potentially stupid: I had expected that lankaster wouldn't get his hd-speedup patches ready for 0.96a, and I was resigned to the same hd-performance as with all older releases. But when I saw them on the newsgroup today I thought I'd try them out just in case, as I could always use my backup-version if they backfired... The point here is that the patch ended up in 0.96a after some minor edits by me (one benign bug and some editing due to changed files). So now hd-performance is much better on most operations. I just hope it doesn't result in yet another release just to fix new bugs (but I doubt it: the patches were really minor and clean - no ugly hacks needed I'm happy to say). Branko already posted benchmarks, and I can only confirm that it's indeed snappier, especially on writes. syncing is no longer a pain even after heavy writing. Other than the hd-performance, there are no new features I haven't already mentioned in other posts. Bug-fixes, rewrites in C, better debugging. I haven't made the cdiffs yet, so right now the new release is only available as complete source and as a binary, but I'll try to get patches done tonight. Possibly tomorrow. The patches will be against the original 0.96, and shouldn't be too big. Linus PS. No need for more 16550 info: even if somebody doesn't implement it for the next release, I think I can get it going. Doesn't seem too hard. I'll also start to look into core-files. Eventually. Promise. PPS. Ja 0.96a on taas saatavilla klaavasta /usr/tmp/linux'ssa yliopistolla kirjoilla oleville. ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Unable to boot 0.96a Message-ID: <1992May23.195321.4721@klaava.Helsinki.FI> Date: 23 May 92 19:53:21 GMT References: <2A1E9A99.25394@ics.uci.edu> Organization: University of Helsinki Lines: 22 Oh boy. I saw the subject line and thought "here it starts again...". Happily, this is a problem that should be easily solveable.. In article <2A1E9A99.25394@ics.uci.edu> bvickers@bonnie.ics.uci.edu (Brett J. Vickers) writes: > The "Loading..." came up, and after >several more "."s, it went into an endless (debugging?) loop of >some sort, putting the following on my screen over and over again: > >@X: 1009 >AX: 0212 >BX: 7E00 >CX: 0901 >DX: 0000 This just indicates that the floppy seems to be bad, or some similar problem. The bootup sequence is pretty unstable, and if there are any problems at all reading in the system, it usually goes into a loop printing out the error-messages. Make sure the floppy is high-density, reformat, and try again. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Patches... Message-ID: <1992May24.104310.16221@klaava.Helsinki.FI> Date: 24 May 92 10:43:10 GMT Organization: University of Helsinki Lines: 28 I finally got around to doing the cdiffs against 0.96, and uploaded them to the usual ftp-archives (nic,tsx and banjo). The patches are actually about 35kB compressed, but they aren't as big as that sounds: it's mainly due to the serial line changes and the fact that the keyboard driver was changed to C. I don't know if somebody is actually going to get the patches instead of the whole distribution, but at least it's available if somebody does want it. If you decide to get 0.96a by patching from 0.96, get the patch-file (diff0.96-0.96a.Z), apply it, and remove the old keyboard.S driver: it is no longer needed. You should also do a "make dep" to get the dependencies up-to-date: I removed those from the cdiffs. I am also going to upload the first set of patches against 0.96a later today. The reason is that the faster harddisk driver had problems with error situations, which I think I've fixed now. The patches also correct the VC restoration with X11 after exiting (but see later). The bugs aren't big enough to require a new version (so far I haven't had a single bug-report on 0.96a: does it really work that well or are people afraid to try it out?), so I'm just making the cdiffs available. As to X: if you are using 0.1 it I'd suggest getting the new version. It corrects the text-mode restoring bug, and with 0.96a with patch 1 applied I haven't seen any problems at all. xterm now handles resizing correctly, and has shrunk considerably due to the multiple shared libraries (from 570kB to 115kB). Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: linux-0.96a.patch1 Message-ID: <1992May24.114643.17027@klaava.Helsinki.FI> Date: 24 May 92 11:46:43 GMT Organization: University of Helsinki Lines: 257 Here is the patch to 0.96a that corrects the harddisk error bug, dup2() and X11 text-mode restoration. Thanks to Rick Sladkey for finding the dup2() bug. This patch has also been sent to the ftp-archives. Linus ---------- *** 0.96a/linux/fs/fcntl.c Fri Apr 24 18:36:09 1992 --- linux/fs/fcntl.c Sat May 23 23:24:24 1992 *************** *** 37,42 **** --- 37,44 ---- int sys_dup2(unsigned int oldfd, unsigned int newfd) { + if (oldfd >= NR_OPEN || !current->filp[oldfd]) + return -EBADF; if (newfd == oldfd) return newfd; sys_close(newfd); *** 0.96a/linux/kernel/chr_drv/console.c Thu May 14 17:40:19 1992 --- linux/kernel/chr_drv/console.c Sun May 24 04:03:01 1992 *************** *** 56,64 **** INIT_C_CC \ } - static void blank_screen(void); - static void unblank_screen(void); - /* * These are set up by the setup-routine at boot-time: */ --- 56,61 ---- *************** *** 223,229 **** { if (video_type != VIDEO_TYPE_EGAC && video_type != VIDEO_TYPE_EGAM) return; ! if (currcons != fg_console) return; cli(); outb_p(12, video_port_reg); --- 220,226 ---- { if (video_type != VIDEO_TYPE_EGAC && video_type != VIDEO_TYPE_EGAM) return; ! if (currcons != fg_console || vt_cons[currcons].vt_mode == KD_GRAPHICS) return; cli(); outb_p(12, video_port_reg); *************** *** 584,593 **** printk("con_write: illegal tty\n\r"); return; } - if (vt_cons[currcons].vt_mode == KD_GRAPHICS) { - flush(tty->write_q); - return; /* no output in graphics mode */ - } while (!tty->stopped && (c = GETCH(tty->write_q)) >= 0) { if (c == 24 || c == 26) state = ESnormal; --- 581,586 ---- *************** *** 834,841 **** state = ESnormal; } } - set_cursor(currcons); timer_active &= ~(1<=NR_CONSOLES) currcons = 0; - if (vt_cons[currcons].vt_mode == KD_GRAPHICS) - return; /* no output in graphics mode */ while (c = *(b++)) { if (c == 10) { cr(currcons); --- 1124,1129 ---- *** 0.96a/linux/kernel/chr_drv/vt.c Wed May 6 21:00:29 1992 --- linux/kernel/chr_drv/vt.c Sun May 24 03:50:43 1992 *************** *** 15,20 **** --- 15,21 ---- #include #include + #include #include #include "vt_kern.h" *************** *** 121,127 **** default: return -EINVAL; } ! vt_cons[console].vt_mode = arg; return 0; case KDGETMODE: verify_area((void *) arg, sizeof(unsigned long)); --- 122,138 ---- default: return -EINVAL; } ! if (vt_cons[console].vt_mode == (unsigned char) arg) ! return 0; ! vt_cons[console].vt_mode = (unsigned char) arg; ! if (console != fg_console) ! return 0; ! if (arg == KD_TEXT) ! unblank_screen(); ! else { ! timer_active &= 1<errors >= MAX_ERRORS) if (CURRENT->bh && CURRENT->nr_sectors > 2) { ! CURRENT->nr_sectors &= ~1; next_buffer(0); } else end_request(0); --- 424,435 ---- return; if (++CURRENT->errors >= MAX_ERRORS) if (CURRENT->bh && CURRENT->nr_sectors > 2) { ! CURRENT->nr_sectors--; ! CURRENT->sector++; ! if (CURRENT->nr_sectors & 1) { ! CURRENT->nr_sectors--; ! CURRENT->sector++; ! } next_buffer(0); } else end_request(0); *************** *** 530,536 **** cli(); if (++CURRENT->errors >= MAX_ERRORS) if (CURRENT->bh && CURRENT->nr_sectors > 2) { ! CURRENT->nr_sectors &= ~1; next_buffer(0); } else end_request(0); --- 535,546 ---- cli(); if (++CURRENT->errors >= MAX_ERRORS) if (CURRENT->bh && CURRENT->nr_sectors > 2) { ! CURRENT->nr_sectors--; ! CURRENT->sector++; ! if (CURRENT->nr_sectors & 1) { ! CURRENT->nr_sectors--; ! CURRENT->sector++; ! } next_buffer(0); } else end_request(0); *** 0.96a/linux/kernel/blk_drv/blk.h Fri May 22 20:56:49 1992 --- linux/kernel/blk_drv/blk.h Sat May 23 17:00:10 1992 *************** *** 149,174 **** wake_up(&bh->b_wait); } - extern inline void next_buffer(int uptodate) - { - struct buffer_head *tmp; - - CURRENT->bh->b_uptodate = uptodate; - unlock_buffer(CURRENT->bh); - if (!uptodate) { - printk(DEVICE_NAME " I/O error\n\r"); - printk("dev %04x, block %d\n\r",CURRENT->dev, - CURRENT->bh->b_blocknr); - } - tmp = CURRENT->bh; - CURRENT->bh = CURRENT->bh->b_reqnext; - tmp->b_reqnext = NULL; - if (!CURRENT->bh) - panic("next_buffer: request buffer list destroyed\r\n"); - CURRENT->buffer = CURRENT->bh->b_data; - CURRENT->errors = 0; - } - extern inline void end_request(int uptodate) { struct request * tmp; --- 149,154 ---- *************** *** 188,193 **** --- 168,195 ---- wake_up(&tmp->waiting); tmp->dev = -1; wake_up(&wait_for_request); + } + + extern inline void next_buffer(int uptodate) + { + struct buffer_head *tmp; + + tmp = CURRENT->bh; + CURRENT->bh = tmp->b_reqnext; + tmp->b_reqnext = NULL; + tmp->b_uptodate = uptodate; + unlock_buffer(tmp); + if (!uptodate) { + printk(DEVICE_NAME " I/O error\n\r"); + printk("dev %04x, block %d\n\r",tmp->b_dev, tmp->b_blocknr); + } + if (!CURRENT->bh) { + printk("next_buffer: request buffer list destroyed\r\n"); + end_request(0); + return; + } + CURRENT->buffer = CURRENT->bh->b_data; + CURRENT->errors = 0; } #ifdef DEVICE_INTR *** 0.96a/linux/include/linux/tty.h Wed May 20 12:15:42 1992 --- linux/include/linux/tty.h Sun May 24 03:46:56 1992 *************** *** 195,200 **** --- 195,202 ---- void copy_to_cooked(struct tty_struct * tty); void update_screen(int new_console); + void blank_screen(void); + void unblank_screen(void); int kill_pg(int pgrp, int sig, int priv); ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux X question Message-ID: <1992May25.093156.8405@klaava.Helsinki.FI> Date: 25 May 92 09:31:56 GMT References: <13489@umd5.umd.edu> Organization: University of Helsinki Lines: 37 In article <13489@umd5.umd.edu> colbert@astro.umd.edu (Edward J.M. Colbert) writes: >I would like to occasionally open an xterm and log in as root -- >without having to shutdown X11 completely. Normally, one could >login as root, but for some reason, when I have X loaded, the only >user I can 'login' as is the one I started X from. What's the >solution? Add the pty devices to your /etc/securetty (or whatever), or root won't be able to log in on a xterm. Also, make login setuid. I /think/ that should do it, but I haven't tried it myself.. As an aside to persons that are having problems with xterm or anything else that uses pty's: make sure your /dev has the correct pty entries. They were wrong on the 0.12 root-disk, I think, and some people have had problems with it. The correct entries are: ptyp0 c 4 128 ptyp1 c 4 129 ... ttyp0 c 4 192 ttyp1 c 4 193 ... (also note that the standard kernel has only 4 pty's compiled into it, and if you want more you have to recompile the kernel. Getting 0.96(a) is a good idea: there were bugs in the pty-code in earlier versions that caused the kernel to hang under certain circumstances) >Also, when X shuts down, I lose my text screen and all of my virtual >consoles. What's going on here? This is an X11 bug and has been corrected in the new version - if you aren't on the X11 mailing-list you won't have seen the message. Shame on you. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: X386 dies prematurely Keywords: linux X386 Message-ID: <1992May25.100710.9861@klaava.Helsinki.FI> Date: 25 May 92 10:07:10 GMT References: <1992May25.040712.17267@infonode.ingr.com> Organization: University of Helsinki Lines: 26 In article <1992May25.040712.17267@infonode.ingr.com> pitaka@infonode.ingr.com (Anucha Pitak) writes: >I got the following message when I ran startx, > >--------------------------------------------------------------- >X386 Version 1.2 / X Windows System [linux version] >(protocol Version 11, revision 0, vendor release 5000) > > >giving up >xinit: Invalid argument (errno 22): unable to connect to X server >xinit: No such process (errno 3) : server error. >--------------------------------------------------------------- > >I have 386-25 (DTK mother board), paradise WD90C00, and microsoft >compatible serial mouse. With these kinds of problems it's usually a good idea to redirect stderr to a file: otherwise some of the error-messages might get lost if they are printed while linux is in graphics mode (this is corrected by the patch1 to 0.96a). X386 usually tries to tell you the reason why it's giving up: it might be due to a missing Xconfig or just bad configuration (ie X doesn't find the fonts where it expected them etc). Try to do a "startx 2&> tmp" and "cat tmp" to see if you get some more information. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: porting screen3.2: possible kernel/library bugs? Message-ID: <1992May25.092323.8195@klaava.Helsinki.FI> Date: 25 May 92 09:23:23 GMT References: <58717@hydra.gatech.EDU> <58836@hydra.gatech.EDU> Organization: University of Helsinki Lines: 65 In article <58836@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS) writes: > >Before I start a flame war on vc's vs. screen(1) here like we just had in >comp.unix.bsd, I'm only interested in the learning experience of what port- >ing a moderately featureful package to linux entails, not using it (except >on serial port logins, of course). Vc's are fine for me. > >Background: screen(1) forks into two processes - screen, & SCREEN. > >1) Compiles crawl if there is a SCREEN running anywhere, even on another >vc. Crawl means 2-3x slower. Kind of surprising, since top(1) shows SCREEN >spends most of its time in do_select. It's real easy to chew up memory too. >Screen(1) takes up 200-300k, plus ~200k for each bash (tho' that may be >comparable to bash on a vc). I would have expected the COW paging to be >more efficient than that. Makes compiling *impossible* after a while >(signal 11). > >Q1) are select() and COW working well? COW - yes, select() don't know. You don't mention which kernel you are running, but select() shouldn't be a problem on 0.96. X uses select() all the time, and I certainly don't see the above kinds of problems. I think both your problems are due to memory limitations: gcc certainly starts to crawl when memory gets tight, and linux starts discarding clean (ie code) pages. Note that linux doesn't give the signal 11 at once when memory is down: first it tries to run the processes by discarding all pages that aren't needed and can be re-demand-loaded in. COW and demand-loading works very well indeed: I routinely have 2MB shared pages when running X or similar. But if you are running on a 2MB or 4MB machine, and are tight for memory, the clean pages are the first thing that linux starts re-using for other things: and as the clean pages are also what can be shared among processes, sharing is no longer as efficient. The above just means that with 4MB of ram, you have 2.5MB free for processes. Assuming you run gcc, that isn't too much, and linux will try to keep only dirty pages in memory. In fact enabling swapping can /improve/ performance in this kind of circumstance: that gives linux a chance to swap out dirty pages, and give more room to code-pages that otherwise would have to be on disk. >Q2) do named pipes have an upper limit on the amount of data that can be >written (2092 bytes above), and is this configurable? (I don't believe the >pipe is being opened w/O_NONBLOCK, but I haven't read the code for the >reader. The writer did not.) Named pipes don't exist in the normal linux kernel, so it's no wonder you can't do anything with them. You can create a special file that looks like a named pipe (the mknod() system call works ok), but there are no routines to actually handle IO on them. If you try, you will get an EINVAL error code, and the kernel will print out a small message telling you why (ie "(read): inode->i_mode = 010600" or similar) >3) if I understand the man page correctly, you should be able to use >setreuid(2) to swap your real & effective uids all day long. The test >program below shows this fails after the FIRST setreuid(2). > >Q3) Why? I haven't got the setreuid manual, and it seems there is a bug in the kernel. I'll have to check it out eventually. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.96 and 0.96a comments (and a bug report) Keywords: kernel bug 0.96 0.96a Message-ID: <1992May25.153807.17572@klaava.Helsinki.FI> Date: 25 May 92 15:38:07 GMT References: <1992May25.151353.4083@cbnewsj.cb.att.com> Organization: University of Helsinki Lines: 14 In article <1992May25.151353.4083@cbnewsj.cb.att.com> nhc@cbnewsj.cb.att.com (n.h.chandler) writes: > >Same here, the "bogus do_no_page" messages are annoying. I >wonder, are they benign or is something nasty happening here? The "bogus do_no_page" message seems to be related to older 386-chips, and right now I'm assuming it's due to a bug in early 386's. Anyway, the 0.96 version seems to handle them cleanly, so you should be able to just uncomment the offending printk() in the sources, and recompile. I left the message in, as I wasn't sure it is 100% ok even in the new version, and I'd rather have too many debugging messages than too few. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: problems with ps, pcomm95c+1 and more... Message-ID: <1992May26.055800.4646@klaava.Helsinki.FI> Date: 26 May 92 05:58:00 GMT References: <1992May24.195213.1118@colorado.edu> Organization: University of Helsinki Lines: 20 In article mattm@starcom.UUCP (Matt Mosley) writes: >> [ ps database ] >> This must be built from the unstripped kernel binary. > >Yes, but *how* do you build it? "ps U XXXX" works for most kernel releases (where XXXX is the name of the unstripped system binary), but with some kernel releases (including the next one) you also have to recompile ps as the kernel structures change. If 'ps U' doesn't work, and you have updated to a new version, this can be the problem: the task-structure has probably changed betweem versions. Note that the next version of linux will use itimers instead of the old alarm interface, and thus the ps sources actually have to be edited a bit, as the alarm structure no longer exists. (No other binaries break, and itimers means you can run xneko...). [ itimers implemented by Darren Senn ] Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: What files to grab ? Message-ID: <1992May27.113053.4804@klaava.Helsinki.FI> Date: 27 May 92 11:30:53 GMT References: <1992May27.072415.23819@ccds3.ntu.edu.tw> Organization: University of Helsinki Lines: 47 In article <1992May27.072415.23819@ccds3.ntu.edu.tw> kcsu@ccds2.cc.ntu.edu.tw (Kuo-Chun Su) writes: > > I am new to Linux. When I connect to tsx-11, I find a lot of files > which I don't quite know. Would anyone tell me what files are needed if > I want to install Linux, including Linux's sources and executables, X11, > GCC, and every other things required to do X programming ? X and gcc are in a constant flux right now: before getting the binaries it's a good idea to join the X11 and gcc mailing-lists. The newest version of gcc is a pre-release of gcc-2.2, and the libraries change almost daily if you really want to keep up. It's a bit of a bother, but the result of it all is that most of the library bugs seem to have been fixed. Other than the compiler and X11, the easiest way to install linux right now is to get the mcc-interim version, and then upgrading to the newest kernel image. The mcc-interim version had some problems with the login binary, but I think they got fixed. The mcc distribution contains most of the basic unix utilities. > Another question. Could anyone describe the pros and cons of Linux > and Coherent 386 for me ? Well, coh386 isn't available for a couple of weeks yet, but this is how I've understood all the hype: Linux pros: - virtual memory, page sharing. VERY BIG pro. - free, full source. - X11 and a lot of other good software already ported. - good support from hackers Coh386 pros: - manual. Easier installation. BIG pro. - runs standard text-mode 386-unix and coh286 binaries. - support from MWC > Also, if Linux more reliable and stable than > BSD386 ? Haven't tested 386BSD, but I assume it will be pretty good in a month or two, and it's probably quite useable already. If you want NFS and full networking, it's the way to go. Comments, anyone? Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: longer filenames dilemma Message-ID: <1992May27.190815.15318@klaava.Helsinki.FI> Date: 27 May 92 19:08:15 GMT References: <1992May27.102933@tioga.ucsc.edu> Organization: University of Helsinki Lines: 37 In article <1992May27.102933@tioga.ucsc.edu> sinster@scintilla.capitola.ca.us writes: >In article , schmid@fb3-s7.math.TU-Berlin.DE (Gregor Schmid) writes: >> Changing this value to s.th. else (preferred 2^n - 2) and recompiling >> should give you a kernel that handles longer filenames (right Linus ?). >> The problem: You have to rebuild mkfs with the new header and remake >> your file system. That's inconvenient but unavoidable. > >Here's the problem bothering me: why does the filesystem have to be rebuilt? >This implies that the full MAX_NAME bytes of space are allocated on the >filesystem for file names. This is very bad. BSD, for instance, uses >a linked-list of filename/inode pairs to represent directories on disk. >This is read into memory and converted to an array of char * for efficiencies' >sake. I'll try to clarify once more about the linux filesystem implementation: Nothing in the linux vfs depends on any particular name-length or on the fact that names are fixed-length: it's just the minix filesystem that doesn't support anything else. You /can/ just change the current routines to use longer names, but this isn't a good idea: as Gregor Schmid noted, this means the old filesystem no longer works. Adding a second filesystem type that doesn't have the minix limitations isn't that difficult: Remy Card did it even in 0.95 as he needed longer filenames in order to compile mach under linux. In 0.96 vfs is a bit better suppoted, so it should be even easier as long as you know what you are doing. Card is now working on a better filesystem (his first one was essentially the minix one, but using 30-character names, I believe), and I hope it will make it into 0.97. When you add a new filesystem by way of the vfs routines, it means that old filesystems are still supported - no need to re-mkfs everything, and copying between filesystems is totally transparent, as long as the underlying filesystem doesn't have some requirements (like 8+3 filenames or similar). Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux swapping Message-ID: <1992May29.171214.8939@klaava.Helsinki.FI> Date: 29 May 92 17:12:14 GMT References: <9spkbss6@cck.coventry.ac.uk> <235kl7h.james@netcom.com> Organization: University of Helsinki Lines: 65 In article <235kl7h.james@netcom.com> james@netcom.com (James L. Paul) writes: >In article <9spkbss6@cck.coventry.ac.uk> csg203@cch.coventry.ac.uk (Bluebeard) writes: >> >>I have 2megs of memory and 4megs of swap. >> >>Does this give me a total of 6megs or only 4 ? It gives you 6MB of memory (but remember that 1MB is used by the kernel). >>A unix expert, told me that the actual memory maps onto the swap, so only the >>swap space above the system memory is available. >>Is this true on linux ? This is true on some unixes (I think SunOS does it that way), but linux uses swap as /additional/ memory. (well, one page of the swap-space is used for the good-page bitmap and the swapspace signature). >>I'm considering upgrading to 4meg of RAM, but as I've only got a 40meg >>partition, I wasn't intending to increase the swap space. I'd sertainly suggest upgrading to 4MB ram and 4MB swap: you'll notice everything is much snappier, especially compiles. >As another Linux beginner, I'd like to hear the answer to this too. >My question is, does Linux swap or page? The use of the term swap is >prevalent in Linux (ie, swap space, swapon) but I also saw descriptions >of swap space given in pages? Linux does only paging, no swapping in the meaning "write out one whole process to disk". The reason I have called it swapping is that linux used paging for memory management on a low level from the first version (0.01), but didn't page to disk at all until version 0.12 (well, there was a testversion out for 0.11, but 0.12 was the first version that did it "officially"). So when paging to disk came along, I called it swapping to distinguish it from the memory management paging linux has done all along. > And is demand paging different from paging? How? Demand-paging is really "demand-loading of executables" and is totally independent of the page-swapping algorithms, although they obviously have similarities. When linux starts up a process, no actual code space is loaded: I let the page exceptions load in the executable as needed. Thus linux demand-loads the code and initialized data it needs. Demand-loading has a couple of very good points: (1) it simplifies the exec system call, (2) it means page-sharing between processes that have executed the same file is easy to implement, and (3) it cuts down on the amount of memory required. When linux runs out of real memory, it starts to look for pages it can swap out: but if it notices that the page is clean, it just forgets about it, and demand-loads it when it's needed again. That means the swap-file isn't needed as much, especially when running big binaries like gcc, where the code-pages can be demand-loaded as you wish. Point (3) means that even without any swapspace, you can usually run slightly larger programs than your memory setup would actually permit. I've noticed this while running X and doing a kernel compile + something else when I've forgotten to turn on swapping: free reports 0 pages available, but things still work, although performance is of course slightly down.. Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux swapping Message-ID: <1992Jun1.181745.15703@klaava.Helsinki.FI> Date: 1 Jun 92 18:17:45 GMT References: <235kl7h.james@netcom.com> <1992May29.171214.8939@klaava.Helsinki.FI> <1992Jun1.134501.3210@bwdls61.bnr.ca> Organization: University of Helsinki Lines: 40 In article <1992Jun1.134501.3210@bwdls61.bnr.ca> mleech@bnr.ca (Marcus Leech) writes: >In article <1992May29.171214.8939@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: >|> When linux runs out of real memory, it >|> starts to look for pages it can swap out: but if it notices that the >|> page is clean, it just forgets about it, and demand-loads it when it's >|> needed again. That means the swap-file isn't needed as much, especially >|> when running big binaries like gcc, where the code-pages can be >|> demand-loaded as you wish. > >A problem with this scheme is that your page-fault latency is limited by the > efficiency of the filesystem. Other OS/UNIX implementations that support > "demand load" executables copy demand-loaded pages into the paging > area after they've been faulted in. Once that's happened, subsequent > faults for the same page come out of the paging area. Paging-area > I/O is typically faster than filesystem I/O by quite a bit, which is > why it's done this way. Yes, paging from a dedicated page-partition is faster than reading in the file from the filesystem, but there were a couple of compelling reasons to do it the linux way. - less wasted resources: why write out the page to a swap-partition when we know it can be found on the filesystem anyway? With gcc and similar big programs, swap-space need is probably reduced a lot by not using swapping for clean pages. - Ease of programming: the linux mm is very simple (1300 lines of C), and I took shortcuts like not keeping track of old pages to get it that way. - If the swapspace is a file, not a partition (which seems pretty usual: I have it set up that way myself), demand-loading is faster: no need to write out the pages, and loading is quite as fast/slow. That said, the current memory manager might have other problems which makes it non-optimal as well: not keeping track of pages very much also means the page-replacement algorithm is somewhat limited (understatement of the year). I felt the simplicity made it worth it. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Is it possible to disable ctrl-alt-del while running linux? Message-ID: <1992Jun2.055143.27888@klaava.Helsinki.FI> Date: 2 Jun 92 05:51:43 GMT References: <1992Jun1.203352.3388@src.umd.edu> Distribution: comp Organization: University of Helsinki Lines: 52 In article <1992Jun1.203352.3388@src.umd.edu> chad@src.umd.edu (R Michael McMahon) writes: >Yes. From kernel/sys.c: > >/* > * this indicates wether you can reboot with ctrl-alt-del: the deault is yes > */ >static int C_A_D = 1; > >Mike chad@src.umd.edu Indeed. Here is a snippet of code that should enable/disable ctrl-alt-del: ---------- #define __LIBRARY__ #include #include static _syscall3(int,reboot,int,magic,int,magigtoo,int,flag) int main(int argc,char ** argv) { if (argc == 2) if (!strcmp("on",argv[1])) { reboot(0xfee1dead,672274793,1); return 0; } else if (!strcmp("off",argv[1])) { reboot(0xfee1dead,672274793,0); return 0; } else if (!strcmp("now",argv[1])) { for (argc=0 ; argc < 5 ; argc++) { sync(); sleep(5); } reboot(0xfee1dead,672274793,0x01234567); return 0; } fprintf(stderr,"usage: reboot [on|off|now]\n"); return 1; } ---------- The program can only be run as root, or nothing will happen. Usage is: reboot on - accept ctrl-alt-del (default) reboot off - ctrl-alt-del is ignored reboot now - reboot after syncing and waiting 25 seconds (so that you can ^C it) And as with most code I write, none of the above has ever been tested: I only guarantee that this is how I intended the reboot system call to work. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Is it possible to disable ctrl-alt-del while running linux? Message-ID: <1992Jun2.055143.27888@klaava.Helsinki.FI> Date: 2 Jun 92 05:51:43 GMT References: <1992Jun1.203352.3388@src.umd.edu> Distribution: comp Organization: University of Helsinki Lines: 52 In article <1992Jun1.203352.3388@src.umd.edu> chad@src.umd.edu (R Michael McMahon) writes: >Yes. From kernel/sys.c: > >/* > * this indicates wether you can reboot with ctrl-alt-del: the deault is yes > */ >static int C_A_D = 1; > >Mike chad@src.umd.edu Indeed. Here is a snippet of code that should enable/disable ctrl-alt-del: ---------- #define __LIBRARY__ #include #include static _syscall3(int,reboot,int,magic,int,magigtoo,int,flag) int main(int argc,char ** argv) { if (argc == 2) if (!strcmp("on",argv[1])) { reboot(0xfee1dead,672274793,1); return 0; } else if (!strcmp("off",argv[1])) { reboot(0xfee1dead,672274793,0); return 0; } else if (!strcmp("now",argv[1])) { for (argc=0 ; argc < 5 ; argc++) { sync(); sleep(5); } reboot(0xfee1dead,672274793,0x01234567); return 0; } fprintf(stderr,"usage: reboot [on|off|now]\n"); return 1; } ---------- The program can only be run as root, or nothing will happen. Usage is: reboot on - accept ctrl-alt-del (default) reboot off - ctrl-alt-del is ignored reboot now - reboot after syncing and waiting 25 seconds (so that you can ^C it) And as with most code I write, none of the above has ever been tested: I only guarantee that this is how I intended the reboot system call to work. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Second patch to 0.96a Message-ID: <1992Jun4.225621.23893@klaava.Helsinki.FI> Date: 4 Jun 92 22:56:21 GMT Organization: University of Helsinki Lines: 43 I have just sent off the second patch to 0.96a: it should be on the normal ftp-sites (nic, tsx-11 and banjo), although the only site which I can make it directly readable on is banjo, so on the other sites it will take the site-managers to make the patch available. Patch 2 implements: - itimers (by Darren Senn), which are now also used to implement the alarm() system call. - ultrastor scsi driver patches (by gentzel) - [f]statfs() system call is implemented (so df can be made fs- independent). Also some other minor fs-changes for the upcoming new filesystem. Patches by Remy Card. - preliminary core-file dumping code (linux creates a core-file, but it's not in the correct format yet [*]). - minor changes/bugfixes. While patching in patch1 is a good idea for anybody, patch 2 isn't really vital. I've made it available just so kernel hackers can keep up with the kernel I have right now if they wish. Patch 2 is relative to patch 1: you have to patch that in first. [*] The current core-file is very simple, and the kernel code is there just so that some enterprising character can expand it. A core-file looks like this right now: offset data 0x0000 "core-dump: regs=\n" 0x0040 struct pt_regs (see ) 0x0400 "floating-point regs:\n" 0x0440 struct i387 (see ) 0x0800 the first 1kB of user-space Not very practical, but it /might/ help if the X-server dies of a segmentation fault or similar (you can use pt_regs.eip to see where it happened). The kernel code is very easy to change to accomodate for the real core-file format, I just didn't know what it should be. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: fsck flags to fix ailing filesystems? Message-ID: <1992Jun5.083629.4527@klaava.Helsinki.FI> Date: 5 Jun 92 08:36:29 GMT References: <1992Jun4.222401.5390@mercury.unt.edu> Organization: University of Helsinki Lines: 46 In article <1992Jun4.222401.5390@mercury.unt.edu> kenc@sol (Ken Corey - Operator) writes: > >Interesting, fsck reports that larvsm are the flags it understands, >but my man page on my (Sun4.1.1a) Unix machine a t work, and on >my (mac)Minix don't show all those arguements. Linux fsck is a quick hack, and not a very good program. I had hoped somebody would expand it to do all the things a real fsck should do, but it seems nobody else thinks it's an interesting project either. The flags are similar to the minix fsck flags (as that's the only fsck I've ever used), and are roughly as follows: l - list all the files on the partition as you fsck. Not very practical, but maybe you want to see what's going on. r - repair any inconsistencies found, asking first if it's ok. a - automatic repairs. Very simpleminded, but doing it by hand is usually not worth it. If the problems are big enough that a doesn't work, you might as well give up anyway under most circumstances. v - verbose: print out some statistics. s - show some super-block info m - warn about the minix "mode not cleared" error: don't do this under linux. > The problem is that >when I first got Linux, I also downloaded the unzip program. > In the course of unzipping something, it trashed by /usr/root >directory. Messing up the pointers somehow, so that the /usr/root >directory could not be romoved. Fsck doesn't handle bad directories at all, so the only thing you can do in this case is to back up everything that seems ok, re-mkfs and re-install that partition. If somebody has hacked fsck to work better in these kinds of circumstances, I'd be interested to know. As to why the errors happened, it certainly seems like a problem with the scsi driver: I don't think it's a race in the fs-code, as this doesn't seem to be a normal occurence. Could drew & co please double-check? Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Problem with 0.96a Patch1 + Patch2 Keywords: linux Message-ID: <1992Jun8.205908.20273@klaava.Helsinki.FI> Date: 8 Jun 92 20:59:08 GMT References: <1992Jun7.142244.27874@ucunix.san.uc.edu> <1992Jun8.120946@banner.ucsc.edu> Organization: University of Helsinki Lines: 27 In article <1992Jun8.120946@banner.ucsc.edu> sinster@scintilla.capitola.ca.us writes: >In article <1992Jun7.142244.27874@ucunix.san.uc.edu>, zuazaga@ucunix.san.uc.edu (Humberto Ortiz-Zuazaga) writes: >> >> What about itimer.c? I kept mine in kernel, and changed the lib/Makefile. > >What? What about itimer.c? There should be _two_ files called itimer.c. >One is lib/itimer.c (this is the library interface to itimers) and the >other is kernel/itimer.c (this actually implements the itimers). > >Is there something odd about the patch? Yes, there is something odd about the patch - lib/itimer.c isn't there. It's not really needed (it's not really kernel code at all), and the only problem is that the lib/Makefile mentions it. I didn't really look through the patch when I made it... As people have noticed, there are several ways to overcome this problem with patch2: the preferred method is just to do a "touch lib/itimer.c" which should make everything work ok. Alternatively, you can edit the makefile and remove "itimer.o" from the OBJS-line. Linus PS. I sometimes get mail I cannot respond to: the latest was from Paul Fraley. If your mailer doesn't set the correct from or reply-to fields, please add a known good email-address to the body of the mail. While it won't guarantee an answer, it at least makes it possible. ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: itimer bit me yet again! Message-ID: <1992Jun10.061543.27737@klaava.Helsinki.FI> Date: 10 Jun 92 06:15:43 GMT References: <1992Jun10.023016.24003@mercury.unt.edu> Organization: University of Helsinki Lines: 20 In article <1992Jun10.023016.24003@mercury.unt.edu> kenc@sol (Ken Corey - Operator) writes: >Okay, I give up. I got the itimer.c file sent out by Dean the other >day...put it in /usr/src/linux/kernel, made sure there WAS a reference to it >in kernel/Makefile, and that there WASN'T a reference to it in lib/Makefile. You did all three things that could fix the problem on their own, but when done all together they break the kernel horribly, as you saw. The original kernel/itimer.c shouldn't be moved: it's indeed a kernel source-file, and contains the sys_[get|set]itimer system call definitions. lib/itimer.c should either (a) not exists: only in that case you should remove the itimer.o from the Makefile, (b) be empty or (c) be the file sinister sent out yesterday. Whichever of these you choose, it's not linked into the kernel anyway, so it doesn't matter from a kernel standpoint: but you can use lib/itimer.o from user space as it implements the itimer library stubs. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: logging the printk output Message-ID: <1992Jun11.102559.295@klaava.Helsinki.FI> Date: 11 Jun 92 10:25:59 GMT References: <3195@sicsun.epfl.ch> Organization: University of Helsinki Lines: 64 In article <3195@sicsun.epfl.ch> lecom@slhp1.epfl.ch (Claude Lecommandeur) writes: > > How can one log the output of all the printk output in a file >(some kind of syslog) ? I'm trying to debug a driver, but all the >good things disapear above the screen. There is no 100% sure way to log the printk() messages, as printk() may not sleep or even pause, but there is already a syslog capability in the kernel that captures everything printed under normal load. It may fail if the buffer fills up without being read by some process, but that is usually not a problem. Here is a program that uses the kernel logging features: #define __LIBRARY__ #include #include #include #include static _syscall3(int,syslog,int,type,char *,buf,int,size) char buffer[1024]; int main(int argc, char ** argv) { int i; errno = 0; if (argc == 2 && !strcmp("off",argv[1])) syslog(0,0,0); else if (argc == 2 && !strcmp("on",argv[1])) syslog(1,0,0); else if (argc == 1) while (1) { i = syslog(2,buffer,1024); if (i < 0) if (errno == EINTR) continue; else break; write(1,buffer,i); } if (errno) perror("syslog"); return errno; } Usage is: syslog on - start logging syslog off - end logging syslog - print the log-messages to stdout until interrupted. for example, under X you can use it to see the log-messages like this: # syslog on # xterm -e syslog & Which will make you a log-window that you can use to see what the kernel prints out while using X. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: what's the kernel need for v 1.0 Message-ID: <1992Jun12.090719.24960@klaava.Helsinki.FI> Date: 12 Jun 92 09:07:19 GMT References: <1992Jun11.203410.15552@athena.mit.edu> <1992Jun12.074133.17546@mnemosyne.cs.du.edu> Organization: University of Helsinki Lines: 57 In article <1992Jun12.074133.17546@mnemosyne.cs.du.edu> zmbenhal@isis.cs.du.edu (Zeyd M. Ben-Halim) writes: >Thomas Dunbar writes: >>What is expected in the kernel in v. .97 ... 1.0? Back in v .11, i felt i >>knew more-or-less what was going to be done. Now, other than stablization of >>GCC, X and the kernel, what's needed? Other than tcp/ip, which i don't care >>much about myself (but who IS working on this?), what's missing? >> i'd like to see a version number soon that suggests Linux, as a whole, >>is no longer in beta-test. Ok, I already answered tdunbar by mail, but in case others are interested: >How about finished VFS layer (or is it already?) The vfs layer is already pretty finished: there should be no more big rewrites as in the 0.95-0.96 diffs. Tweaking etc will naturally go on (as with any other kernel feature), but it's mostly there. >shared memory >semaphores >ipc messages I'd like these eventually, and I might try to implement them during the summer, but no promises. In any case these certainly aren't required for a 1.0 version. >file and memory locks Well... I'm not too hot about file locking, but we'll see. >named pipes This is already available as a patch. I haven't applied it yet, but I will as soon as the author feels it's ready (and I agree). >STREAMS >screen mapping with page faults on bank crossing (video card dependant :-( >AF_INET sockets Not me. Hopefully somebody else implements it so cleanly that I cannot do other than accept it :-) >Any fs besides minix Definitely. This is one of the points keeping linux beta. 0.97 should contain it. >What Linux NEEDS is a stable GCC (one that does not evolvo every 2 days) and >an easy method of updated shared libs (jump tables or whatever) Yes. And easier installation. And manuals/guides/whetever. I know I have been hoping to make 1.0 available for a long time - right now I expect it to be here by the end of summer. By that time gcc and the libraries should have stabilized, and hopefully the ABC-release or similar is ready. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Patch2 is a bad patch if it doesn't compile Message-ID: <1992Jun13.074121.21900@klaava.Helsinki.FI> Date: 13 Jun 92 07:41:21 GMT References: <1992Jun9.163918@dana.ucsc.edu> <1992Jun12.143353.2356@aw2.fsl.ca.boeing.com> Organization: University of Helsinki Lines: 28 In article <1992Jun12.143353.2356@aw2.fsl.ca.boeing.com> vds7789@aw2.fsl.ca.boeing.com (Vincent D. Skahan) writes: > >Could Linus please either release a patch3 so that we're up at the >current version and can just hit 'make' or release a patched-up 'good' >set of sources ??? Patch3 won't be out before there is some good reason for it: right now I haven't changed the sources enough to warrant it. >I thought the whole point of releasing a patch was to permit people >to get to the same baseline version to work off of... > >I'm not installing anything above patch1 if I have to tweak anything >to get it to compile... This is the normal reasons for patches, but patch2 was a bit special, and documented as such: the /major/ reason for the release was just to make the preliminary core-dumping code available to kernel hackers, so that somebody who had better docs etc than me could implement the correct format for core-files. This indeed happened, and the next release will have post-morted debugging (and hopefully attach and detach). So if people don't feel comfortable with patching, patch2 can safely be left out (although it does fix some minor bugs as well: the open() error-value etc). Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux and Me II Message-ID: <1992Jun13.081917.22210@klaava.Helsinki.FI> Date: 13 Jun 92 08:19:17 GMT References: Distribution: comp Organization: University of Helsinki Lines: 14 In article burley@geech.gnu.ai.mit.edu (Craig Burley) writes: > >The upshot is that it looks like the files are all okay on disk, but that >sometimes Linux misreads the data, convincing diff that files are different >when they aren't. The differences seem more suggestive to me of block-level >(OS-interface-level) problems, though since I haven't looked at how diff is >implemented, I cannot be sure it isn't a diff bug (though it'd have to be >a random bug). It's something in the SCSI drivers, and I'd suggest getting the newest drivers from headrest.woz.colorado.edu: they might correct the problem. Obviously, I haven't tested them... Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: mtools question Message-ID: <1992Jun15.105210.7613@klaava.Helsinki.FI> Date: 15 Jun 92 10:52:10 GMT References: <1992Jun14.025750.2388@CSD-NewsHost.Stanford.EDU> <1992Jun14.190521.12355@bernina.ethz.ch> <1992Jun14.225856.27315@unixland.natick.ma.us> Organization: University of Helsinki Lines: 13 In article <1992Jun14.225856.27315@unixland.natick.ma.us> bill@unixland.natick.ma.us (Bill Heiser) writes: >almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes: >>>> Hard links have the advantage that they only occupy an inode each while >>>> symbolic links additionally consume one disk block (1kB). > >Is this meant to imply that LINUX has symbolic links? Indeed. Has had them since 0.12 I do believe. I think the original 0.12 didn't allow symlinks that contained other symlinks as part of them, but later versions have had a loop count of five, which is quite enough for everything I have yet seen. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: anyone using 20 MB RAM? Message-ID: <1992Jun15.191710.20349@klaava.Helsinki.FI> Date: 15 Jun 92 19:17:10 GMT References: Distribution: comp Organization: University of Helsinki Lines: 22 In article pnakada@oracle.com (Paul Nakada) writes: > >Linux Hackers - > > I'd like to add 4 4MB SIMMS to my system for a total of 20 MB RAM. >Does anyone have Linux running with this amount of memory? Are there >any gotchas I should know about? Thanks. The standard linux distribution uses memory only up to the 16MB mark; you'd have 4MB unused (but it's still a great idea). There is a 32MB patch (mainly just sets up a few more page tables), but it won't work with the current SCSI-drivers I think. The reason 16MB is a problem is that DMA won't go beyond that, and although the floppy-driver is coded to take care of this, I don't think the scsi drivers are (there was a problem with going above 2MB with the 0.95 scsi release with some card). If you don't use swapping (and with 20MB you can run a lot even without swapping), linux won't try to copy directly to the >16MB pages anyway, so the 32MB patch is safe in that case. Likewise if you aren't using scsi. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: patch3.... Keywords: patch 0.96a Message-ID: <1992Jun15.200454.21058@klaava.Helsinki.FI> Date: 15 Jun 92 20:04:54 GMT Organization: University of Helsinki Lines: 43 Ok, I already announced it on the kernel mailing-list, but I might as well go all the way. I put out patch3 to 0.96a yesterday, and it's available on banjo in pub/Linux/Linus, and I'll upload it to the other normal ftp-sites tonight. NOTE! Patch3 is (like patch2) more of a kernel-hacker patch: it's just in case you want to keep up with my kernel. It has some problems with some serial lines, and if you experience them, I'd like to know what type of chip you are running (and what linux reports on bootup). If you don't think patching the kernel is fun, you might as well forget this and wait for a real release (next month?). Patch 3 contains: - support for attaching and detaching processes under gdb (but you need a gdb that knows about this). - 16550A support - full core-dumping (again, you need a gdb that supports it) - sockets have no problems with non-root binding etc - /dev/zero implemented (mknod /dev/zero c 1 5) None of the patches are very big (the whole patch is 17kB compressed, most of it attach/detach code), but they are all pretty useful. The 16550A support means that with the appropriate chip you now should be able to use the serial ports at much higher speeds, but as mentioned, it seems to break on some machines. The detaching isn't perfect yet (I noticed only after making the diffs that I had forgotten to do some cleanups), but it's not generally a problem (the code just forgets to give the process back to it's rightful father). The patch is relative to the pl2 kernel, so you have to use the earlier patches first. This time, I've added the lib/itimer.c code. 16550A support was written by tdavis, the correct format of the core-dumps was written by eric (who also wrote the attach/detach code I used as an example when implementing it), /dev/zero was written by almesber. Nice to see good patches: I just did the socket-thing and rewrote the attaching to suit me. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: get/setitimer() Message-ID: <1992Jun15.223433.23669@klaava.Helsinki.FI> Date: 15 Jun 92 22:34:33 GMT References: <708635438snx@hectic.demon.co.uk> Organization: University of Helsinki Lines: 23 In article <708635438snx@hectic.demon.co.uk> mike@hectic.demon.co.uk (Mike Davies) writes: >Now that X seems to be well established on Linux ... (flame proof >suit at the ready) ... I've tried to compile a couple of contributions, >with a varying amount of success. > >However, a stumbling block in at least one case is setitimer(). >Have I missed something (quite likely), or this still missing in Linux ? >If so, is it likely to appear shortly ? If not, is there a work-round ? set/getitimer doesn't exist in the basic 0.96a kernel, but after applying all the patches (1-3) it should work well. The only thing I have which actually uses it is xneko, so I haven't tested it to exhaustion.. Note that code that uses get/setitimer also often assume the BSD signal() behavior instead of the linux (posix) stuff, so you might have to edit the sigblocking functions and rewrite signal() calls to use sigaction(). The get/setitimer() library stubs are now in patch3, and you have to add them to the library in order for programs using them to link ok (ie add the lib/itimer.o file that gets created by a kernel make to the static libc.a. Maybe the newer gcc-2 libraries already have it). Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: linux scheduling Message-ID: <1992Jun15.231313.24182@klaava.Helsinki.FI> Date: 15 Jun 92 23:13:13 GMT References: Organization: University of Helsinki Lines: 99 In article pnakada@oracle.com (Paul Nakada) writes: > >Could someone (linus?) please give a high level description of the >scheduling mechanism in Linux? The scheduler in linux is pretty simple, but does a reasonably good job at giving good IO response while not being too unfair against cpu-bound processes. Simply put: Linux gets a timer-interrupt at every jiffy (100 Hz), and decrements the current->counter. If current->counter is zero, and the process isn't running in kernel mode, the scheduler() is called. Also, when a process is woken up and it's counter is greater than the current process, a flag is set, which forces the re-scheduling. The scheduling is pretty simple: when schedule() is called, the process that has the highest non-zero counter and is runnable is run. If no runnable process exists, task[0] ("swapper") gets to run, but it currently doesn't do anything. In the future, the swapper task might do page-aging or similar. If all runnable processes have a zero counter, the schedule() algorithm goes through all processes once more, giving them a new counter-value of "priority+counter/2". It might seem useless to add the counter/2, as counter is 0, but in fact this is done to /all/ processes, including sleeping ones, which thereby get higher counter-values for when they wake up. The above algorithm seems to be pretty fair, and works well while being very easy to understand. It also gives much snappier response than many systems I've seen. And it's all done without any queues at all, which I find clean and simple. In fact, the scedule() algorithm isn't more than a couple of lines in C, and going to sleep or waking up is just a matter of setting the process status and calling schedule(). >a) a process calls a kernel trap; >b) process enters kernel mode, current processor state saved. In fact, the current processor state is never saved anywhere as in "normal" unices. A kernel trap under linux is very much like a system call: registers get saved on the stack as needed, but we don't mess around with updating task-structures etc. >c) pop return address from stack and save No, let it lie on the stack: when the process returns it gets restored. Why save it anywhere else? >d) kernel initiates disk i/o and places process on i/o queue >e) get next active process >f) push return address on stack and return from handler to new process >g) process times out > etc etc etc. It's all much simpler than this: the process, running in kernel mode, does what it wants, and if it wants to sleep, it just does current->state = TASK_INTERRUPTIBLE; schedule(); assuming it has made sure it will wake up some way (due to signals or the kernel time-out feature or by putting the task-struct address in a wait-variable). The other processes run happily in between, and when something causes the process to wake up, it just continues after the schedule() call. When it's done all the things the system call (or page-exception or whetever) required it to do, it just does a return, and it's back in user mode. As to how schedule() switches tasks, it's builtin in the 386, so it's actually just a couple machine-code instructions. It's slightly more complicated than just a jump through a task-segment, as it checks that it's not the same task, and for minimal 387-saving by testing the "last_task_used_math" variable and doing a clts if possible, but it's still less than 10 insns. To understand what /really/ goes on, you'd better read a 386 book, but it's not too complicated if you just care about the general idea. >why do i ask this? I've been studying the scheduling code for a >couple days, trying to absorb enough to take a stab at improving >response time under heavy disk i/o. I can understand the parts as >separate modules, but it's not obvious to me how they work together as >a system. I imagine it's second nature to Linus and other veteran >kernel hackers, but all I've got is an OS class from a few years back. I doubt the scheduler is the problem when it comes to response-time under heavy disk i/o. It's probably at least partly because of the way buffer-cache blocks are locked, which sometimes forces the buffer algorithms to sleep on them unnecessarily. Thus if a buffer-request comes through when blocks are locked due to actual IO, the request sometimes blocks just to make sure there are no races. I'd take a look at fs/buffer.c before doing anything else. But be /very/ careful when changing buffer.c: it's very easy to add a race-condition if you don't think of all the possible things that can happen due to interrupts etc while a buffer is searced for. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Size-change of ino_t Message-ID: <1992Jun16.161638.20159@klaava.Helsinki.FI> Date: 16 Jun 92 16:16:38 GMT Organization: University of Helsinki Lines: 37 With the eventual advent of bigger filesystems (and a DOS filesystem is being developed), ino_t (currently unsigned short) is no longer really big enough. 65535 (0 is reserved) inode numbers might be too little on bigger filesystems, and the DOS filesystem will use sparse inode numbers that will require more than 16 bits in order to be efficient. No problem: just change it. Right? Wrong. That will also change the size and offsets in the 'stat' struct (), which is used by almost every program currently in use. While recompiling /everything/ might be a good idea, even gcc won't probably run, so it would have to be done by a kind of cross-compilation from the current linux version to the new version. That's simply not practical. What I intend to do is to keep the old stat() system call and return just the low 16 bits of the inode number in it (might still break under bigger fs's, but it's very unlikely, and only on a user level), and create a new stat (and fstat) system call that has the full information. Ugly, but with the current installed base it's impractical to do any other way (in 0.11 I would probably have gone all the way and simply recompiled everything). Why post here? Two reasons: (1) I want to know if people feel there are other structures that really /need/ to be upgraded (for future expansion), so that I won't have to have several different stat() interfaces, and (2) just to warn people about it, and maybe get some comments. Note that while a lot of programs use the stat() system call, they usually don't actually care about the inode number, so it's not essential that all programs be recompiled. Things that actually /need/ the full inode number include tar (uses i to verify if two files are actually had-linked together), pwd (find the root that way) and and to a lesser extent things like cpp ('#pragma once' uses it, I believe). Old binaries of these programs might become unreliable when/if somebody actually gets a filesystem that uses more than 65535 inodes. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Floppy errors at end of disk (Re: Aachen binaries now at rs6000.cmp.ilstu.edu) Message-ID: <1992Jun16.195611.24568@klaava.Helsinki.FI> Date: 16 Jun 92 19:56:11 GMT References: <1992Jun15.180815.12006@rs6000.cmp.ilstu.edu> <1992Jun16.152453.29511@tc.cornell.edu> <1992Jun16.192910.17381@rs6000.cmp.ilstu.edu> Organization: University of Helsinki Lines: 14 In article <1992Jun16.192910.17381@rs6000.cmp.ilstu.edu> jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) writes: > >Anyone know why this might be? I am using the Adaptec 1542b floppy >controller built into the card, and get block read errors at the end of >each disk. This also happened during mkfs at block 65536 on my hard drive, >even though I specified "mkfs -c /dev/sd02 65535." Its as though linux >doesn't stop reading/writing when it reaches the end of the disk... Yes, it's a problem with the read-ahead routines that read ahead past the end of the disk... It's fixed in patch2, I think (and if it isn't it's in patch3), but it's totally harmless except for the error messages, so you can ignore them if you wish. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 32-bit inodes: patch4 Message-ID: <1992Jun18.145012.17636@klaava.Helsinki.FI> Date: 18 Jun 92 14:50:12 GMT Organization: University of Helsinki Lines: 12 Ok, patch4 implements 32-bit inode numbers (and thus the new stat/lstat/fstat system calls), as well as correcting the bad rs-performance on some machines that showed up in patch3. It's currently only on banjo, but I'll copy it around eventually. Again, you don't miss much if you don't use this patch: it's mainly for (a) the serial problems and (b) for hlu etc that want to test out the 32-bit interface. It does some other magical tricks as well (uses less memory in the low 1M region by moving the screen and tty buffer to high memory), if anybody is interested. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: ET4000 speedup (was Re: 16 bit video access on systems with additional monochrome adapter) Message-ID: <1992Jun19.124336.8707@klaava.Helsinki.FI> Date: 19 Jun 92 12:43:36 GMT References: <1992Jun18.201538.15449@athena.mit.edu> <1992Jun18.210717.19512@serval.net.wsu.edu> Organization: University of Helsinki Lines: 28 In article <1992Jun18.210717.19512@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes: >In article <1992Jun18.201538.15449@athena.mit.edu>, arybicki.lax1b@xerox.com writes: >|> >|> While on the subject. Does X386 for Linux have the ET4000 speedups from >|> export.lcs.mit.edu? I've heard that they greatly improve the performance of >|> X386 drawing. They would definitely make xmartin work quicker. > >I don't if I want it. From my understanding, it only supports 1024x1024. No, they only limit the /virtual/ screen size to 1024xXXX, which means that you can't run with screens wider than 1024 pixels, but that's usually no problem. Having a 800x600 resolution mode should be quite possible tiwh the speedup patches (but you'll need 1MB video-ram, as minimum virtual resolution is 1024x600 in that case). The reason for the above limit is that that there are no pixel-lines that are partly in one segment, and partly in another, so checking for VGA segments is much reduced, giving faster routines. The original X386 routines as more general, but have the obvious speed disadvantages: (S)VGA isn't a very good graphics implementation. I think the speedup patch is actually in the X386-1.2e version that is currently in beta-testing (not under linux yet, though), so eventually we'll see a release that supports the faster ET4000 modes as well. I don't know if obz has the beta-test release, or if he will be able to use it in the near future, so don't hold your breath. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Linux v 0.96b available Keywords: new version 0.96b Message-ID: <1992Jun21.231223.18826@klaava.Helsinki.FI> Date: 21 Jun 92 23:12:23 GMT Organization: University of Helsinki Lines: 59 I have uploaded my newest kernel sources and a US-keyboard image to both tsx-11.mit.edu and nic.funet.fi. I'll put it on banjo too as soon as banjo wakes up (that's when I'll do the patches too: I'll need access to banjo to get a 0.96a.pl4 kernel to make patches against..). As usual, it will probably be a day or two until the files have been moved from the incoming directory to their proper places. 0.96b is not a new major release: it's pretty close to 0.96a with all my patches (1-4). However, as there has been 4 patches already, I decided it would be time for a full kernel release along with a bootimage, so that people who don't feel confident with patching can use the new features. If you already have 0.96a patchlevel 4, 0.96b will offer you these new features: - the math-emulation now handles fsqrt, as gcc-2.2.2 generates that inline. I haven't tested the kernel code at all: I tested the algorithm in user space, but I'm lazy, so I never turned off my 387 to do real testing. I hope it works. - better vt100 terminal emulation thanks to Mika Liljeberg. - I removed a possible race-condition in the buffer-cache code. - minor fixes The vt100 emulation should now be complete enough for almost everything (including vt100 test suites): as a result the setterm utility had to be changed (as the old setterm codes aren't compatible with the full vt100 codes). setterm-0.96b.tar.Z contains the new setterm. The soon-to-be-released gcc-2.2.2 will need the 0.96b kernel: (a) due to the fsqrt emulation and (b) it uses the new stat() system call. So upgrading is a good idea. (If you have a co-processor, (a) isn't used, but (b) still stands) If you have an unpatched 0.96a, the differences to 0.96b are roughly (not counting the above-mentioned new things): - corrected the disk-buffer-list bug with read/write-errors - fixed read-ahead warning messages at end of disk - better support for text-mode restoration after running MGR and X - full core-dumping, attach/detach etc debugging features - 16550A support - less low 1MB memory used for kernel structures - various minor fixes Note that the fact that new versions (pl4 and above) use more memory in the 1M+ area means that linux will report less free memory (it's used for buffer-cache instead). This could concievably be a problem on 2MB machines. The standard kernel comes with only 4 pty's though, and if you use the standard 80x25 text modes instead of svga modes, the VC buffers will be smaller. Please contact me if there are problems even with this minimal setup. 0.96b does /not/ contain: the new scsi drivers, new filesystems or some other patches I have gotten (ibm character set mode, loop-devices etc). If you have sent me any other patch, you might want to remind me about it. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 32-bit i-nodes??? Message-ID: <1992Jun22.211849.15768@klaava.Helsinki.FI> Date: 22 Jun 92 21:18:49 GMT References: <1992Jun22.191501.5047@athena.mit.edu> Organization: University of Helsinki Lines: 30 In article <1992Jun22.191501.5047@athena.mit.edu> williamsem"%mrgate."netspo.a1.decnet@space.laafb.af.mil writes: > >A few days ago, I saw the announcement of 0.96a patch 4 that included (among >other things) 32-bit i-nodes. I looked in the patch and saw the new stat >functions and the new syscall numbers, but couldn't really see what had >changed. Not too surprising: the changes are just to make future filesystems easier to write. The current filesystem still uses only 16 bits for the inode numbers, and the changes were just the internal representation (and the new system call interface so that things will work when the new filesystems arrive). > In particular, what impact does this have on the disk itself? What >really confused me is that the 32-bit i-node feature was not listed in the >0.96b announcement today! Could someone please clarify what the 32-bit I-node >change really did? Sorry about the lack of mention in the 0.96b announcement: the 32bit inode numbers are definitely in, and I just forgot to mention it (it wasn't any of the really /new/ features. What the 32-bit change really did was to make it possible for persons writing new filesystems to use more info to specify an inode: this was needed at least for the DOS fs. I hope this means that 1.0 will be able to mount DOS filesystems, and the mtools package will be a thing of the past. It has no immediate impact on anybody else than hlu, who had to update the libraries (gcc-2.2.2 will use the new interface). Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Too much uneaten serial causes system hang? Keywords: LINUX serial ports, uneaten characters Message-ID: <1992Jun23.172824.16843@klaava.Helsinki.FI> Date: 23 Jun 92 17:28:24 GMT References: <1992Jun23.140938.5621@cseg03.uark.edu> Organization: University of Helsinki Lines: 26 In article arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes: > >YES! I have noticed this VERY exact thing also! Oh, well: it's a bug in the serial drivers that I have already fixed, but I haven't done the c-diffs yet. I have rewritten big parts of the serial line code to be more easily configured for different IRQ numbers, and I noticed the bug while doing that. I'll make patch1 for 0.96b available later today or tomorrow. patch1 will be mostly just the serial driver code: it allows changing the irq's (and port addresses) of serial devices on the fly (with an ioctl call), so people that have ser4 on irq5 etc shouldn't have to recompile the kernel. It also returns EBUSY if you try to open a serial line that shares the irq-line with another line etc. Another change in patch1 will the the handling of ctrl-alt-del: it will send a SIGINT to the init process if the reset-function is disabled. This makes it ideal for a controlled shutdown, but it does need a /bin/init that knows about this. Linus PS. It seems both the DOS-fs and the extended fs will be out for alpha-testing next week, so I assume 0.97 will have them both if things work out ok. ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: FAQ-finding mission 2: demand paging Message-ID: <1992Jun24.100236.5849@klaava.Helsinki.FI> Date: 24 Jun 92 10:02:36 GMT References: <1992Jun22.215658.13564@colorado.edu> Organization: University of Helsinki Lines: 25 In article hermit%dastari.uucp@devon.lns.pa.us writes: > >You shouldn't be able to write to a demand-paged executable that is >being executed. An open for writing should return ETXTBSY in that >case. (creat() should also fail, I imagine.) Linux doesn't care, and indeed there is no difference between opening a normal file and opening a file for demand-paging. I don't think ETXTBSY is worth any extra code: (a) it doesn't happen in practice and (b) if it does: so what. If you have write permissions to your executables and overwrite them with something else, you deserve everything that's coming to you. If somebody writes patches to add the ETXTBSY detection, I might use them if I feel they are clean enough, but I certainly am not going to implement it. I've used demand-paging on linux for six months (that's pretty exactly how long it has been in there), and I have never seen any problem with it. Similarly with the swap-space file (and shared libraries). If somebody overwrites swap data the kernel doesn't care: your user-space programs might not do too well, though. Swapspace and binaries should be non-writeable by normal users (and at least swapspace should be non-readable), and if you are root you can hose the system more easily than by overwriting binaries. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Problems compiling & escape sequences Message-ID: <1992Jun24.131806.10059@klaava.Helsinki.FI> Date: 24 Jun 92 13:18:06 GMT References: <92175.235813U30207@uicvm.uic.edu> Organization: University of Helsinki Lines: 26 In article <92175.235813U30207@uicvm.uic.edu> U30207@uicvm.uic.edu (Harry Georgopoulos) writes: > > [ sending escape sequences to the printer ] Assuming you have bash, the easiest way to send escape-sequences to the printer is: $ echo -e -n "\033E" > /dev/lp1 sends the sequence ESC + 'E' (usually "emphasize on") to thelp device. The "-e" means that echo uses the escape sequences (\033 = dec 27 = esc = ^[), and the "-n" means that the echo doesn't send a newline. >gcc -O -g -o basename basename.o ../lib/libshu.a version.o >ld:No such file or directory for libg.a >make[1]: *** [basename] Error 1 This comes up with some regularity: 2.2.2 has a libg.a, but earlier versions didn't. You can either compile without the "-g" flag, which makes debugging pretty much impossible (but makes the binaries much smaller), or create a dummy libg.a in the library subdirectory (which is different depending on which gcc version you have: try /usr/lib/static or /usr/lib/lib-gcc/i386-linux/2.2 or similar depending on the version. The dummy libg.a is created with "ar cvs libg.a". Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Bug in fsqrt emulation Message-ID: <1992Jun25.115206.8160@klaava.Helsinki.FI> Date: 25 Jun 92 11:52:06 GMT Organization: University of Helsinki Lines: 35 I won't make a patch2 for this one, but 0.96b(.pl1) has a one-character bug in the fsqrt emulation code that results in fsqrt resulting in zero all the time. The following patch corrects it (thanks to Rick Sladkey for noting it: I hadn't tested the code, so I never saw it...) ---------- cut cut ---------- --- sqrt.c.orig Thu Jun 25 00:00:00 1992 +++ sqrt.c Wed Jun 24 23:59:37 1992 @@ -55,7 +55,7 @@ src[3] = s->b; d->exponent = 0; d->a = d->b = 0; - if (exponent) /* fsqrt(0.0) = 0.0 */ + if (!exponent) /* fsqrt(0.0) = 0.0 */ return; if (!src[2] && !src[3]) return; ---------- cut cut ---------- That is, add the missing '!' and recompile the kernel. This bug naturally doesn't show up on machines with a co-processor, and isn't noticeable unless you have programs compiled with gcc versions > 2.1, as earlier versions didn't use the fsqrt instruction. At least one other known bug in 0.96b.pl1 is that a serial line open that fails due to EBUSY (ie another serial line using the same irq-line is active) will still incorrectly add 1 to the tty->count. You don't usually see this bug, but it can result in bogus EBUSY errors later on. This and the fsqrt bug are already fixed in my version, and I'll make patch2 available when I have some more fixes. Other things added by patch2 will include correct CS5-8 and parity handling on the serial lines (and HUP on setting the speed to 0). Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Logitech mice problem revisited. Message-ID: <1992Jun25.123636.9214@klaava.Helsinki.FI> Date: 25 Jun 92 12:36:36 GMT References: <3264@sicsun.epfl.ch> Organization: University of Helsinki Lines: 29 In article <3264@sicsun.epfl.ch> lecom@slhp1.epfl.ch (Claude Lecommandeur) writes: > > I did much investigation on why my logitech mouse (MouseMan M-MC13) >doesn't work with X11. This mouse is supposed to be Microsoft compatable >but isn't. The normal sequence (microsoft) for button1 click without >moving is hexa : 60 0 0 (seven bits, no parity, 2 stop bits) i verified >it is true with another microsoft compatable mouse (genius). But the >logitech one send, (or at least i read on /dev/ttys1) : 60 40 40. > > This mean that the seventh bit on the 2 last bytes are set to one >and they should be set 0. I was told by Logitech that actually, there >is a difference between their mice and microsoft : there is only one >stop bit instead of two. But setting -cstopb does nothing at all. Ok, it does indeed seem to be the bad support for CS7 in the linux kernel. It seems I'll have to make patch2 available earlier than I thought: I have implemented full CS7 support now, and if that is what it takes to get some mice to work with linux, patch2 should correct it. Expect the new patch tomorrow. Thanks for a good report: these kinds of things really help when it comes to correcting kernel features. As it happened, I added the support before I saw this post, but that's just luck. Patch 2 also supports the CSTOPB bit, which earlier linux versions ignore (along with PARENB/PARODD and the CSx settings). I hope the mice problems will be gone after this patch. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.96b PL2 Pty's broken? Message-ID: <1992Jun28.071057.14601@klaava.Helsinki.FI> Date: 28 Jun 92 07:10:57 GMT References: <1992Jun27.202738.7487@bmerh85.bnr.ca> Organization: University of Helsinki Lines: 20 In article <1992Jun27.202738.7487@bmerh85.bnr.ca> dgraham@bmers30.bnr.ca (Douglas Graham) writes: >Was there a reason why the following patch was applied to the read_chan >code in 0.96b PL2? Now, a "cat /dev/ttyp0" will return immediately after >having read 0 bytes, instead of hanging waiting for something to be >written to the master side. Among other things, this breaks "script". [ patch which returns 0 in read() if the other end of a pty is not open ] I got a report that the above was the correct behaviour, so when I implemented it and nothing I used broke, I added it to patch2. It seems it wasn't the right thing to do. I'd like to know the correct behaviour, so if you have documentation, please tell me how a pty should react to read, write and open when the other end isn'c open yet. I also changed the open() on a pty slave to wait until the master is opened, but I put a #if 0 ... #endif around it (see chr_drv/pty.c), so it isn't used right now. Could someone please mail me the correct semantics for these cases? Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: writing 96b image to floppy Message-ID: <1992Jun28.065802.14240@klaava.Helsinki.FI> Date: 28 Jun 92 06:58:02 GMT References: <74577@ut-emx.uucp> <709500596snx@hectic.demon.co.uk> Organization: University of Helsinki Lines: 15 In article <709500596snx@hectic.demon.co.uk> mike@hectic.demon.co.uk (Mike Davies) writes: > >I'm getting worried about this. I always do 'cp Image /dev/PS0', >and it works fine. Everybody else uses dd. Can someone tell me >if I'm doing a *very bad* thing ? cp works fine, but dd was a /lot/ faster with the old floppy driver that didn't do track buffering. With the current kernel there's not too much difference between cp and dd, so you can safely use cp now. (Another reason I use dd in the kernel Makefile is that some old version of GNU cp "optimized" the copying by not copying zeros (doing a lseek() over them instead), which works fine on regular files but breaks on special files like /dev/PS0. Newer cp's don't have this problem) Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: FIFO's Keywords: A Message-ID: <1992Jun30.172600.7661@klaava.Helsinki.FI> Date: 30 Jun 92 17:26:00 GMT References: <1992Jun30.154421.20029@ucc.su.OZ.AU> Organization: University of Helsinki Lines: 21 In article <1992Jun30.154421.20029@ucc.su.OZ.AU> chrisa@extro.ucc.su.OZ.AU (C. G. Albone) writes: >Hello * > What is the latest news on FIFO's? Will there be anything >near ready for release soon? I got the patches for named pipes from Paul Hargrove, and while I had some problems with them (you don't want to know), they are now corrected and seem to work well in my system. I edited them a bit while searching for the bug, and I haven't really tested them extensively yet, but at least they should be in the next release. Right now I'm wondering if I should make a small patch3 that contains mainly that code and some other minor fixes, or if I should do the alpha extended filesystem patches first and try to have 0.96b.pl3 support 4TB fs's and long filenames. It depends on how the ext-fs patches seem. Assuming the extended filesystem poses no problems, next week should see a patch that contains them. After that I'll do the DOS fs patches, and then I'll probably relax a bit and let people work on the new file systems to find the bugs. We'll see. Linus ================================ ================================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Patches.. (Was re: ) Message-ID: <1992Jun30.210216.12584@klaava.Helsinki.FI> Date: 30 Jun 92 21:02:16 GMT References: <1992Jun30.004140.4543@athena.mit.edu> <1992Jun30.155048.6563@spuddy.uucp> Organization: University of Helsinki Lines: 98 In article <1992Jun30.155048.6563@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes: > >However, the problem I forsee with projects like this is a lack of >(i) co-oridnation >(ii) quality control Indeed. I try to keep both these going, but it's not exactly easy. The biggest problems are (a) features that I haven't used too much before (and thus don't know the exact semantics), (b) hardware peculiarities or simply hardware I don't have and finally (c) lack of infinite time and energy. (a) can result in some weird behaviour (like the pty change in pl2) while (b) results in code I cannot check. (c) is pretty obvious :) >I'm sure Linus would hate to have to rigorously check EVERY patch that >goes to him - he'd never have any time to program himself :-) Most of the patches I get and apply are quite thoroughly checked by me both by reading the actual cdiffs (which is why I often insist on diffs instead of new files even if the diff is about the same size) and by then reading and possibly modifying the code. And several patches either aren't used or are heavily modified. The biggest patch that I didn't check is the SCSI drivers: it's essentially useless to wade through code when you can't change it anyway for being afraid you break something. It shows pretty well in the sources too: the scsi drivers look quite different from the rest of the kernel. Most other patches have gone through pretty rigorous checking: some have looked definitely different after I have had my way with them. So, if you do kernel patches, and want them included in a future release, here are a few points that can make it go faster: - mail it to me. If it's more than a couple of hundred of lines of compressed uuencoded patches, you had better talk with me about it first: patching more than that is definitely not something I like to do without a very good reason. I won't fetch patches from ftp-sites unless there is some good reason for it. - do it in small separate parts. If you fix a lot of things, send several small patches rather than one big one. That way I can (a) more easily see what the patch does, and (b) select and edit the patches more easily. - follow the same programming style as the rest of the kernel (not counting the scsi drivers). That means tabs and the normal linux brace placing. If I like the look of the code, it's easier for me to follow and I'm definitely not above disliking a patch just for visual reasons. Even when the above holds true, I might not patch it in for several reasons: - If I don't like the way something is implemented, I usually skip it completely, or then I might write my own version if I find it an interesting and useful patch. Not liking it can be due to several reasons: bad special case checking, bad coding style, weird and long functions and uncomprehensible algorithms. Or any number of things. - hardware reasons: if I don't have the hardware I'm less likely to patch it in. The scsi drivers went in because they were obviously needed (and didn't clutter the rest of the kernel). This is definitely why I still haven't looked at the ethernet patches nor the bus-mouse driver: both might be vital to some, but... - if I'm busy with other things or the patch doesn't go in cleanly due to other patches, I might just forget about it and hope the patcher makes a new version for the next release. Some patches have had to wait for several releases until I implemented them. - simply because I don't feel it's important enough. Bug-fixes and important fundamental new features definitely get priority, as well as some things I simply consider interesting. - they don't fit well with something I've been thinking of doing. This goes for the VM86 patch: it's an interesting concept, but to make it go in cleanly I'll have to re-write the mm a bit first. The current mm patches for VM86 are something of a hack, and might make it difficult to correct the mm later. And while VM86 is good, a clean mm is more important right now. The result of all this is that if you want a patch to go in, you have to (a) tell me about it (b) make me understand that it's really nifty (the itimers patch went in the day I noticed xneko wanted them :-) (c) do it cleanly: linux is a hackers kernel, but that definitely doesn't mean ugly hacks are encouraged (d) tell me about it some more. If you feel something needs bigger changes (like the msdos filesystem needing 32-bit inode numbers), it's a better bet to mail me and ask about it, and I might do it myself just because I feel better about it after that. Also note that the fact that I don't use it doesn't really matter: some patches are quite useable just as patches. Or as complete systems from somebody else than me: if somebody thinks a linux system with "unofficial" patches would be useful, it's certainly a good idea. Several packages have come with kernel patches just because the standard kernel didn't support them (the original X and ps095 both had kernel patches in the distribution to add the necessary features.) Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Logitech mice Message-ID: <1992Jul2.225253.7764@klaava.Helsinki.FI> Date: 2 Jul 92 22:52:53 GMT References: <3300@sicsun.epfl.ch> Organization: University of Helsinki Lines: 31 In article <3300@sicsun.epfl.ch> lecom@slhp1.epfl.ch (Claude Lecommandeur) writes: > > For all the people (like me) who lost hope of making their logitech >mice, Apply right now the patch2 to 0.96b. It works perfertly. Thanks to >Linux. I'm happy that the second patch does indeed seem to correct the problems (or at least most of them) people had with some mice. I just wanted to say that there is a pretty bad bug in patch2, which happily is easy to correct (even without an additional patch). The problem occurs if you try to open a tty special file that doesn't have any device connected to it: ie if you try to open /dev/ttyp4 and the kernel has been compiled for just 4 pty devices (ttyp0-ttyp3). The result of the open is an instant reboot. The above holds true for all other "undefined" tty devices as well: if you have created a nonexistent /dev/tty9 (the ninth virtual console when only 8 are defined by the kernel) and try to open it, things don't work too well. Most people haven't defined any extra special devices, but those who have should remove them. The problem is in the tty_ioctl.c file: in the functions flush_[in|out]put() which don't check that the queue's actually exist sufficiently. I have corrected it already, and patch3 (probably out Saturday) will contain this fix as well as some other new features (the alpha code of the extfs, named pipes, corrected console handling etc). In the meantime everybody who uses patch2 should make sure they have no bad tty special files (major = 4) in their /dev directory. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: To Linus, Lions book? Message-ID: <1992Jul3.113506.20524@klaava.Helsinki.FI> Date: 3 Jul 92 11:35:06 GMT References: <1992Jul3.090424.15207@athena.mit.edu> Organization: University of Helsinki Lines: 96 In article <1992Jul3.090424.15207@athena.mit.edu> J.Jagger@sheffield-city-poly.ac.uk writes: > >How did you get all your now how to create Linux? >Was hands on learning, which books/mags/articles/code >did you read? Go on Linus, give us a potted life history :-) Heh. I can't let these ego-building posts go by, so I'll have to answer it. Linux started for several different reasons: originally just to learn the 386, and for this the book "Programming the 80386" by Crawford and Gelsinger is a must. At least I haven't found anything better (although admittedly bookstores in Finland probably don't have the plethora of books available over in the US etc). The 386 book info has been used for all the 386 details: the lowest level of the task-switching code, memory manager, floating point emulations etc. It doesn't even mention the AT hardware, so for device drivers you'll need more info, but it does contain everything on the 386/387 chips (even if it's a bit hard to read: read it through several times before starting to look into details). The device drivers have been written mostly by trial and error: I haven't found a single good source of info on the standard AT hardware. Helpful sources have been (a) the AT Technical Reference Manual (notably the BIOS listing) (b) actual data-sheets for the 8250 etc chips used in the AT hardware (c) other sources (mach drivers and to a lesser extent minix drivers) (d) various books like "IBM Microcomputers: a programmers manual", "The PC Sourcebook" etc. Even though there are a lot of books on the AT hardware, none of them seem to approach the information content of the 80386 books. I can't recommend any of the sources I've used, and the best bet is probably to have a lot of books and hope they together cover most of it. Then there is naturally the hardware-independent parts of the kernel: general filesystem/process/memory management. The two books I originally used were "The Design of the Unix Operating System" by Bach, and "OS Design and Implementation" by Tanenbaum. Tanenbaum's book should be read a couple of times: ignore the details (especially about minix), but get the general picture clear. The Bach book has a few nice algorithms in it, and I'd suggest reading them too: many of the actual ideas on how something could be implemented came from that. Still, OS design is mostly common sense: it doesn't need complicated algorithms like a compiler does or similar. A lot of thought, careful programming and some good decisions. And unix is a very simple OS really: I first came in contact with it 2 years ago when I did the "C-kieli ja unix ohjelmointiymp{rist|" course in the fall of -90. By early -91 I had bought a PC, and linux v0.01 was ready in August -91. That wouldn't have been possible with some other systems I could mention (VMS.. arghh). The most difficult parts are: - device drivers: you can go crazy trying to find why something doesn't work on some machines (especially if you can't even test it out). - filesystem: trying to make it clean and well designed, as well as getting rid of all race conditions. The current linux vfs layer seems to work well enough, but my original design wasn't too good. Rewriting big parts isn't fun when something works. The kernel proper is pretty simple in fact, although you have to keep track of a lot of things. The memory manager has also survived pretty well all the changes, and although I'll have to change it to use different page directories for different processes some day it will probably look pretty similar even after that. >Also could you mail me a few lines, grouping the source code >files into chunks. I.e., which files make up the lowest most >basic layer of the OS 'onion', which ones make up the next layer? >This would make it lot easirt to peruse the code in an orderly fashion >so I can try to understand it. Hmm. To get a good general idea of the different pieces, I'd suggest reading linux/*/*.c - all the memory management sources, the normal kernel sources and the vfs routines. They are pretty modular: you can generally understant linux/fs/*.c without having to understand the kernel and vice versa (for a general picture, that is. For the details you usually have to read it all). The linux device drivers (linux/kernel/chr_drv and linux/kernel/blk_drv) are a pain to read: they don't actually give you any more info on the kernel itself, so reading them is only needed if you really want to know how a block is loaded into memory etc. Similarly for the math-emulator (linux/kernel/math). The special filesystems (linux/fs/minix and now linux/fs/ext) can be read if you are interested in the actual lay-out of the disk, or if you want to see how some of the fs races are handled. Note that most race-conditions are handled directly by the buffer-cache routines or the vfs layer, but some races are inherent to the actual fs implementation (renaming a file etc). Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Speed of GCC Message-ID: <1992Jul3.180739.26258@klaava.Helsinki.FI> Date: 3 Jul 92 18:07:39 GMT References: <1992Jul3.133741.18573@tc.cornell.edu> Organization: University of Helsinki Lines: 31 In article <1992Jul3.133741.18573@tc.cornell.edu> elan@tasha.cheme.cornell.edu (Elan Feingold) writes: > >This may be a stupid question, but I'm wondering why GCC is so Slooow... >All my MSDOS (yech) compilers (i.e. Borland) compile things very much >quicker. I could understand a RISC compiler being much slower, as it >has to handle many more things, but under 386 LINUX I would think it >should be faster... There are several reasons for gcc being slow under linux: - it's big: if you haven't got much memory (4M or less), it generally swaps, and doesn't fit in the buffer cache. With 8MB or more, gcc is pretty ok speedwise. - it's good: it does a lot of things that many DOS compilers don't do. - as all GNU software, it has been mostly developed on big and fast machines: size and speed of the compiler has been very much a secondary issue. - it's general: it has been written to work on several different platforms and produce code for many different processors. As with most problems, that automatically means it's slower than something that is specially written for one architecture. Also, IO etc can in many cases be faster under DOS than under linux: a single-tasking system can make shortcuts that aren't possible under a "real" OS. (Not that djgpp under DOS is faster than gcc under linux: but that's because djgpp has to do a lot of ugly things to work at all). Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Compiling 0.96b kernel with gcc 2.2.2 Message-ID: <1992Jul3.212912.29760@klaava.Helsinki.FI> Date: 3 Jul 92 21:29:12 GMT References: <23300@castle.ed.ac.uk> <23334@castle.ed.ac.uk> <1992Jul3.191439.12493@nwnexus.WA.COM> Organization: University of Helsinki Lines: 30 In article <1992Jul3.191439.12493@nwnexus.WA.COM> vince@halcyon.com (Vince Skahan) writes: > [ deleted ] >/dev/hda1: Function not implemented >Couldn't stat root device. >make: *** [Image] Error 1 > > >....the (sadly) interesting thing is that if I use the 2.2.2 compiler > to make the shellutils, textutils, etc, there are certain > of those programs that, when executed, give the 'Function not > implemented' message listed above... Well, the reason is very simple: the gcc-2.2.2 library uses the new stat() system call, which isn't (surprise surprise) implemented in kernel versions 0.96a.pl3 and below. Thus the very logical "Function not implemented". The gcc docs do mention the fact that you must be running 0.96a.pl4 or above. The solution is (a) to get the 0.96b image from the ftp sites and use that while compiling the new kernel (or utilities) or (b) to use an older gcc while running the old kernels. (a) is preferable. If somebody missed the discussion, the reason the stat() system call was changed was to make a new 'struct stat' available that supports 32-bit inode numbers as well as the st_blocks fields (although they are actually 0 in linux-0.96b.pl2 and below). And while all old binaries work fine under the new kernel, newly compiled binaries automatically use the new stat() system call. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Anyone collecting bugs out there? Message-ID: <1992Jul4.202540.21929@klaava.Helsinki.FI> Date: 4 Jul 92 20:25:40 GMT References: <1992Jul4.184224.24930@dg-rtp.dg.com> Organization: University of Helsinki Lines: 28 In article <1992Jul4.184224.24930@dg-rtp.dg.com> welshm@mirage.rtp.dg.com (Matt Welsh) writes: >I've got a question-- is there anyone who's been collecting the many >various bug reports for Linux posted to this group? >I was just thinking, it might be a nice idea to have someone in charge >of getting bug reports (either by e-mail directly for from postings >to this group), compiling them into one big report (that could be >kept updated) so that new (as well as experienced) Linux users could >grab a copy of the most recent bug report and see if the problems they're >having are true verified "bugs" in Linux or have workarounds (and are >due to different setups, i.e using the wrong version of GCC with >a certain patchlevel). This was tried a while back: there was a whopping bug-file available at tsx-11.mit.edu at some time. The problem was that most of the bugsreports were very quickly outdated (and, as you say, due to installation problems in some cases). I doubt the bug-list ever got very useful, even though the idea was good. As with many things, the speed of linux development makes documentation difficult. Most bugs reported on the net are (a) either hardware-related and thus very difficult to check out or (b) the bug-report is followed by a fix, and thus keeping the report is not very practical. The best way to avoid bugs is generally to have the newest kernel (even though some bugs are introduced with new versions.. on the whole things get better with higher version numbers). I hope that 0.96c (ie 0.96b.pl3 - out later today) will fix all known non-hardware bugs. Knock wood. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.96c out Keywords: kernel release Message-ID: <1992Jul4.232540.25763@klaava.Helsinki.FI> Date: 4 Jul 92 23:25:40 GMT Organization: University of Helsinki Lines: 41 The latest kernel version is 0.96c: the binary and sources can be found on banjo.concert.net: pub/Linux/Linus as usual. I haven't made the cdiffs yet, and I'll upload those tomorrow (at the same time I'll put it on the other sites as well). 0.96c is actually what I called patch3 earlier this week, but as the new features were pretty big and the cdiff's are probably going to be bigger than the normal patches, I decided I might as well make it a totally new minor release and make a bootimage and complete source available. 0.96c contains: - bugfixes (tty, console driver, pty's, sockets) - fifo's (names pipes - Paul Hargrove & editing by me) - the alpha extended filesystem (Remy Card) - st_blocks implemented (ie du, ls give reasonable if not exact values for disk-space used) - Makefile cleanups and warnings at compile-time removed Note that while the extended filesystem code is there, and this kernel successfully mounts and uses the new filesystem (with long filenames and >64MB partitions), it's still under testing: I haven't made the mkefs program available, and the extended filesystem features shouldn't be used for other than testing right now. Some of the changes are just cleanups: most of the warnings when compiling the new kernel should be gone (not counting the scsi code which is still the old non-cleaned-up version), and the make'ing of the kernel is more logical now. The bugfixes include the corrected console.c driver, the socket corrections (without which X sometimes locks up), some pty semantics corrections (although I'm still not certain it's correct) and some editing in the general tty driver (including fixing the bug introduced in 0.96b.pl2 that caused a reboot with uninitialized tty devices). While the extended filesystem support isn't "official" yet, I can happily report that my limited testing hasn't found any problems with long filenames etc. It still needs a fsck program, but 1.0 looks like a real possibility soon. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.96c out Keywords: kernel release Message-ID: <1992Jul5.074120.3661@klaava.Helsinki.FI> Date: 5 Jul 92 07:41:20 GMT References: <1992Jul4.232540.25763@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 18 Earlier I wrote: >The latest kernel version is 0.96c: the binary and sources can be found >on banjo.concert.net: pub/Linux/Linus as usual. I have had one report that 0.96c won't compile with an older gcc even though 0.96b does ok. The solution is to get gcc-2.2.2: that's what I use (the problem was the console.c file, specifically the asm statement in scrup() - some gcc versions seem not to be able to keep enough registers free for it). If you are unwilling to get the new compiler, you might have to stay with 0.96b.pl2 (or just get the new binary). Also note that if somebody uses the extended-fs features, you'd want to recompile most programs with 2.2.2 anyway: that way they use the correct vfs readdir() function (reading a directory directly won't work on the ext-fs) and the new stat() functions. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Bug in 96c! Message-ID: <1992Jul8.090104.29648@klaava.Helsinki.FI> Date: 8 Jul 92 09:01:04 GMT References: <13d04pINN8fo@matt.ksu.ksu.edu> Organization: University of Helsinki Lines: 23 In article <13d04pINN8fo@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) writes: >Just an annoying bug I found with 96c. When I run X and then exit from it, the >system hangs. Not completely, the keyboard comes back, but typing on it does >nothing. (i.e. characters appear, but no response from linux) Yes, it's a bug, but it's already corrected in my version: the weekly patch (probably out this weekend) will correct it. The problem is the TIOCCONS ioctl: if you use "xterm -C" to get console output redirected, the redirection doesn't stop correctly when the pty is closed. What you are seeing is a linux system with the output redirected to a pty that is no longer in use. The reason it showed up in 0.96c is that the pty usage-counts changed a bit in order for the pty's to have the correct behaviour when one end is closed: but I forgot about redirection which depended on the old behaviour. The bug isn't too bad: the system doesn't actually crash, and if you wait 30 secs, update does it's job and you can reboot safely. Or you can avoid it altogether by not using "-C" with 0.96c for now. (patch1 will mostly be internal changes for the irq-lines, although there are a few patches in there and the above fix). Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: ftruncate bug Message-ID: <1992Jul8.175040.10667@klaava.Helsinki.FI> Date: 8 Jul 92 17:50:40 GMT Organization: University of Helsinki Lines: 32 There is a typo in fs/open.c: sys_ftruncate() where the write-permissions are checked from the f_flags entry instead of the f_mode structure-entry. It results in ftruncate() failing on files opened with O_RWONLY. This resulted in the weird behaviour for the GNU 'cp' command when it's compiled with all the new libraries etc. The problem shows itself when GNU cp copies a file that ends with zero's, and cp tries to make a hole in the file. GNU cp writes one byte past the end, and then uses ftruncate() to get the right file-length. On 0.96c and earlier this results in EACCES, and cp reports someting like cp: Permission denied and exits. The file is mostly good: it's just one byte too long and doesn't get the right permissions (as cp gives up before doing the chmod). As this only happens with files that have zero's at the end, you don't usually notice it even if you have a new version of cp. The fix is easy: either wait for patch1 (still out this weekend), or fix it yourself. I haven't made patches yet, but it looks something like this (line 94 in fs/open.c, function sys_ftruncate()): if (S_ISDIR(inode->i_mode) || !(file->f_flags & 2)) return -EACCES; Just change the f_flags to f_mode, and everything is well. Also note that this bug doesn't matter for older binaries: ftruncate is a pretty new system call in linux, so few binaries actually use it. It also happens to work correctly if the file is opened with O_RDWR. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Disk cacheing Message-ID: <1992Jul10.091409.20803@klaava.Helsinki.FI> Date: 10 Jul 92 09:14:09 GMT Organization: University of Helsinki Lines: 19 Oh, boy. >10 messages today about the fs cache - a totally unnecessary waste of space. This is my $0.02: - the buffer cache stays the same. That's it. If somebody wants to get rid of caching, change the source and see if you really want it to stay that way. I'm not going to remove cacheing even if I get patches, but maybe you can make a non-cache release on your own. If somebody wants more frequent sync's: the update program is 10 lines long, and changing it to update every other second or so would certainly effectively disable the write-cache. Or add the automatic sync to bash: "PROMPTCMD=sync" or similar. Or use DOS. I don't know where people get their numbers, but I do know that gcc runs at least twice as fast if you have a decent cache. End of discussion. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Patch1 to 0.96c out Keywords: 0.96c patch Message-ID: <1992Jul11.204011.21601@klaava.Helsinki.FI> Date: 11 Jul 92 20:40:11 GMT Organization: University of Helsinki Lines: 62 [ I already sent this to the normal mailing-list, so you can skip this if you already got it by mail ] I have sent off my first patch to 0.96c: as usual it's available directly from banjo.concert.net while nic.funet.fi and tsx-11.mit.edu might take a day or two to put it into the right directories. linux-0.96c.patch1 contains more changes than I originally envisioned: I changed the IRQ routines and the serial code to be easier and cleaner (and hopefully more efficient) and I thought that would be it. I was wrong. I got several patches (and one bug-report) again, and while I haven't had time to check them all, some of them are in. Fixes: - Remy Cards correction to the out-of-space problem with the extended fs is here. Most people using the ext-fs might already have applied this patch, in which case you might have problems patching. - my ftruncate() fix is here. Again, if you already did the trivial patch by hand, you'll get errors when patching. - almesber's implementation of read-only filesystems is here (after editing by yours truly). The mount() system call now accepts a flags integer as well as a pointer to some arbitraty data in user space for some special mount() calls. The general flags allow (a) read-only mounting, (b) disabling of suid executables (c) disabling of device special files and (d) total disabling of executables on a per-filesystem basis. The filesystem specific mount() info isn't currently used by any fs, but can be used to specify additional information that depends on a special fs type (a password or similar would be possible..) - the rename() system call had a bug in that it allowed moving over a directory: I think the code to handle this was lost in the vfs editing, and although the GNU mv utility checked it, a malicious (or just unsuspecting) program can destroy the fs using this. Thanks for the bug-report: it was very easy to add once I saw the problem. - support for vesa-standard svga cards in setup.S. I'm unable to test this, but my svga card still works after the patch, so I left it in in the hope that it doesn't break for anybody else. - various minor editing by me, or minor patches sent in by others. The full cdiff is almost 50kB compressed, so this is a bigger-than-usual patch. Hope there are no problems. People who are using the new SCSI drivers might have problems with my changes to the SCSI irq-setup changes, so be careful (actually using the original sources might be a good idea, and then upgrading again). I hope to get the new SCSI drivers into the kernel soon (definitely in time for 0.98). I'd be interested to hear comments on serial line performance, bugs, features, etc. As usual, I'm hoping this release won't contain any new bugs while fixing all the old ones, but I guess that's likely to happen right after the first winter olympics in Hell. Linus PS. Maybe nobody noticed, but I actually never made the patches to 0.96c available. As nobody has complained, I assume everybody just got the complete kernel sources and used that. Unless somebody actually asks for them, I don't think there is any point in making them any more. ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Floppies (was Re: File system issues!) Message-ID: <1992Jul12.104841.2039@klaava.Helsinki.FI> Date: 12 Jul 92 10:48:41 GMT References: <1992Jul10.140622.4927@email.tuwien.ac.at> <1992Jul10.164650.2229@rs6000.cmp.ilstu.edu> Organization: University of Helsinki Lines: 44 In article <1992Jul10.164650.2229@rs6000.cmp.ilstu.edu> jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) writes: > >Doesn't the autodetect feature on fd0, fd1 already detect when a floppy has >been changed. I know under mtools I often get a message to the effect that >"the floppy is undefined because it has been changed". Mtools does not >leave the motor running. Perhaps this feature could be incorporated into >the standard linux floppy read/writes, if it hasn't already. Floppy change detection has been there since the beginning of the floppy driver (linux-0.11, I think. Note that the harddisk driver was there from the beginning), but only the autodetect floppies actually say something about it (as they have to re-detect the media, and the debugging info was a good way to make sure it detected them correctly). The main problem has been (a) some hardware simply doesn't send the correct floppy-changed signal (notably old drives: at least some 360kB 5.25" drives) (b) some bugs in the early code (linux in fact thought a disk had been changed even when it hadn't in some circumstances). (b) should be corrected now (thanks to almesber: the floppy-changed signal is reset by seeking a bit), while (a) is still a problem on some (very few) drives. [ Note: the floppy-change signal is checked only when opening and mounting a floppy: if you change the floppy while the device is open or mounted you are in for some surprises ] >On another note, has anyone considered making 1.72 MB disks a la fdformat >for DOS readable under Linux? Check out the floppy ioctl()'s: along with the auto-detecting, almesber added support for forcing the floppy to use a user-defined setup, which can include these kinds of user-defined sizes (but note that the track-buffer is used only if there are <= 18 sectors per track, so you get bad performance with nonstandard formats beyond that). That said, the floppy driver is a mess. It's been changed and hacked on like the other drivers, but as it's a pain in the *** (and very boring) to program floppies, nobody has really cleaned it up. It's gotten better performance and features over time, but it's one of the pieces that should be taken out and shot. But I'm not going to, as writing a new one is just too depressing. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Device names (was Re: ttys2 not responding) Message-ID: <1992Jul12.181359.6939@klaava.Helsinki.FI> Date: 12 Jul 92 18:13:59 GMT References: <710808938.F00117@remote.halcyon.com> Organization: University of Helsinki Lines: 54 In article <710808938.F00117@remote.halcyon.com> Rob.Levin@f217.n3802.z1.fidonet.org (Rob Levin) writes: > >Well, if we're going to be consistent, shouldn't we *then* change the >*local* consoles to tty[0-7]? Otherwise, we have tty[1-8], but >ttys[0-3], which isn't terribly consistent.... If you don't have tty0, your installation is lacking: tty0-8 are perfectly valid console devices. BUT tty0 is special: it's not limited to just one of the virtual consoles, but is always the current one. tty0 should be used if you have some important message that you want to make /sure/ is printed on the console regardless of which VC is in use (the same way kernel messages are always printed to the current console) If you don't have the tty0 device, you should create it with # mknod /dev/tty0 c 4 0 and also make the /dev/console the same device (either by linking or making a similar special file for it). >Well, far be it from me to splash water, doesn't the existence of >/dev/fd0 and /dev/fd1 sort of render all this complication *moot*? Are >there any situations where autodetect could *not* be used successfully? >If not, are there any situations where one would *want* to use the more >cumbersome forms simply for consistency purposes? There are some circumstances where the auto-detect floppies cannot be used: the most obvious of these is when formatting disks, as there is no way for the driver to auto-detect an unformatted floppy. Also, if somebody wants to make his own floppy formats and code them into the kernel (and it's not too hard to do), the new floppy naming scheme will hopefully give him/her obvious names for the non-standard devices even though the auto-detect code doesn't recognize them. Having a fairly obvious naming standard for these kinds of devices shouldn't hurt. >P.S. Shouldn't we consider starting our hard disk partitions with >/dev/hda0...? If not, why not...? ;-) Actually, the current /dev/hda is a kind of /dev/hda0 (check the minor device numbers) - but in order to make doubly sure that nobody confuses the device with a normal partition (/dev/hda is the whole first HD), I decided on the current numbering when I finally chucked the minix naming over-board. I haven't regretted it: while there were no end of problems with the old names, everybody seems to understand the new naming conventions. [ For those that don't remember the old minix naming mess: /dev/hd0 was the current /dev/hda, /dev/hd1 was /dev/hda1... /dev/hd5 was /dev/hdb, /dev/hd6 was /dev/hdb1. The numbers were directly linked with the minix minor numbers, and resulted in major confusion ] Linux ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: selecting irq's Message-ID: <1992Jul12.200240.8864@klaava.Helsinki.FI> Date: 12 Jul 92 20:02:40 GMT References: <1992Jul11.043103.28342@athena.mit.edu> Organization: University of Helsinki Lines: 38 In article <1992Jul11.043103.28342@athena.mit.edu> Brad.Midgley@m.cc.utah.edu writes: > >How do I tell linux about the strange irq's which my serial ports above >2 use? Can anything go wrong if I don't tell it these irq numbers but >don't use those ports either? Even if the ports have weird IRQ setups, that shouldn't hurt if you don't use them (unless they are /truly/ weird and interfere with the harddisk or something, but that's not very probable (understatement of the year)). >I haven't looked at the source yet, but I assume that linux will not let >you open two serial ports which SHARE the same irq, but once you let it >know that, say, port 3 uses irq 2, it will let you open both at the same >time, no? Yes, you can have as many serial ports open as you wish, as long as they don't share IRQ's. 0.96c + patch1 should be truly free about the serial IRQ's: it should be possible to set them up to anything as long as it doesn't interfere with anything else. Of course, I have used the "Linus' Extended Testing System" (pat.pend.) on all this, so it's (almost) guaranteed to work (*). Note that earlier versions (a) required kernel patches to use any non-standard IRQ's, or (b) only supported a limited number of different serial IRQ's (0.96b.pl2 handled irq2,3,4 and 5). 0.96c+patch1 should be dynamically configurable to use /any/ free IRQ line (and port address). Linus (*) "Linus' Extended ...", (ie LETS) is a revolutionary concept: you write the code, pray to God it works, and if God doesn't contradict you, you release it as an "Official Patch" (tm) after which you pray none of the beta-testers contradict you either. It doesn't always work, but it sure cuts down on the time needed for testing. (**) (**) No, I'm not totally serious. Ha Ha. I've just been on the lines too much. I'm much better now. Really. ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: race condition if minixfs?? Message-ID: <1992Jul13.103705.25008@klaava.Helsinki.FI> Date: 13 Jul 92 10:37:05 GMT References: <1992Jul12.041727.24125@news.Hawaii.Edu> Organization: University of Helsinki Lines: 30 In article <1992Jul12.041727.24125@news.Hawaii.Edu> oles@spectra (Shawn Oles) writes: > >I can't figure out how the following race condition(?) is avoided in >Linux's : > >What happens if two processes, (A & B), are trying to find a free block >on the same device. If process A interupts at and B >comes into "minix_new_block", aren't they both going to grap the same >block, which would result in a system panic on the set_bit ? Processes cannot be interrupted by another process (only a hardware interrupt - and they don't switch tasks) when they are running in kernel mode unless they actually sleep. And as no interrupt calls minix_new_block, there is no need to check for races. Things that can sleep and thus be interrupted by another process: Obvious: scedule() [un]interruptble_sleep_on() any IO except printk() Not so obvious: accessing user-space memory (remember: it might swapped out or not be loaded) As minix_new_block doesn't do any of the above (the buffers that it searches are already loaded), it doesn't sleep -> no other process runs during that time. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Disk cacheing Message-ID: <1992Jul13.101550.24190@klaava.Helsinki.FI> Date: 13 Jul 92 10:15:50 GMT References: <1992Jul10.091409.20803@klaava.Helsinki.FI> <1992Jul12.071717.20019@cheshire.oxy.edu> Organization: University of Helsinki Lines: 22 In article <1992Jul12.071717.20019@cheshire.oxy.edu> rafetmad@cheshire.oxy.edu (David Giller) writes: > >Agreed. But... Could we please have a second thought about at least >upgrading the existing buffer cache? Oh, I didn't mean I wouldn't be open to changing implementation details, algorithms etc. Even to disable write-caching for one partition or so is no problem: add a flag to the mount() call (easy in 0.96c.pl1) that is the equvalent of O_SYNC for a file (which isn't implemented either). It will take some code to actually implement it, but probably not too much (and note that it wouldn't be default, but people might do something like "mount -t ext /dev/hdb1 /usr/spool sync" to get it to work). What I just reacted against were the big number of posts that wanted "a better DOS than DOS" or something similar. Frankly, as long as the arguments are on that level, I essentially ignore them. That doesn't mean I don't understand arguments like "I'd like to run linux as a newsfeed, and write-through would help". Although actual patches are an even more convincing argument :-). Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Splitting the comp.os.linux group Message-ID: <1992Jul13.213830.13210@klaava.Helsinki.FI> Date: 13 Jul 92 21:38:30 GMT References: <1992Jul13.093121.27993@wega.rz.uni-ulm.de> <1992Jul13.150727.7923@cl.cam.ac.uk> Organization: University of Helsinki Lines: 45 In article <1992Jul13.150727.7923@cl.cam.ac.uk> qs101@cl.cam.ac.uk (Quentin Stafford-Fraser) writes: > [ comp.os.linux subgrouping ] >|> Is there anyone out there of the same opinion? > >I think almost everyone is - There have been several postings to this >effect, with slight variations on the names of suggested groups, and I >have seen no dissenters. Any split would be an improvement - let's get >on with it. Who do we need to persuade to actually get the thing done? No, everybody does not think this is a good idea: admittedly the traffic on comp.os.linux has been high and varied, but I don't think we really need more newsgroups. I don't really think the traffic is big enough to support several groups, and I think the right solution is to try to find a threading newsreader if at all possible (like trn). Most of the discussion is (a) how/where to get linux and beginners questions: this shouldn't require a newsgroup of it's own but just better docs etc. (Not that I'm about to write them :-) (b) general discussion that would have to be in comp.os.linux anyway. The number of questions relating to a limited area (like X11) isn't really that high, and it has dropped (in the case of X) lately, or so I think. One argument for newsgroups has been that there are mailing-lists that people feel would be nicer to have as a newsgroup: but the mailing-lists and the newsgroup really have different uses, and should be separate (for one thing having a mailing-list for a well-defined area like the standards-list cuts down the noise-level a bit when compared to a newsgroup). A newsgroup like comp.os.linux.beginners may sound like a good idea, but I doubt it would actually work: people would crosspost to the "real" group anyway, and while it's sometimes irritating to see the same questions over and over, I don't think we can get rid of them. (Well, other than by making everybody afraid of posting because they get flamed, which I don't feel is a good idea: some of the replies have been a bit acerbic, and I've gotten a few mails directly to me, because people actually don't like posting due to that. Not good.) As to something like comp.os.linux.X11 - the idea is to get X working so well under linux that no such group should be needed: the normal X group should answer most questions. Hopefully the same goes for things like "rm ./-i" that should really be in comp.unix.wizards (heh. Try it some time :-) Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Badblocks revisited (**sigh**) Message-ID: <1992Jul14.105705.7189@klaava.Helsinki.FI> Date: 14 Jul 92 10:57:05 GMT References: <1992Jul13.054522.15674@cc.umontreal.ca> Organization: University of Helsinki Lines: 12 In article mper@uipsuxb.ps.uiuc.edu (Michael Pereckas) writes: > >Is it possible for the read-ahead code to read ahead into some bad >blocks? Yes, it's possible. It shouldn't happen when using the device as a filesystem, but it can happen when doing a fsck or reading from the raw device. In that case you should be able to ignore the messages: if you don't feel comfortable with that, you can remove the read-ahead code on block devices altogether. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: [comp.os.linux]: Re: File system issues! Message-ID: <1992Jul14.112136.7798@klaava.Helsinki.FI> Date: 14 Jul 92 11:21:36 GMT References: <9207131519.AA14556@optical.bms.com> Organization: University of Helsinki Lines: 40 [ sorry if the attributions are wrong: the included file was a bit messy ] In article unixsys@ssg.com (Rick Emerson) writes: > From: davidsen@ariel.crd.GE.COM (william E Davidsen) >> >> Perhaps that class of user should be using fsync() to force their data >> out. fsync() under linux isn't implemented right now: although a fsync() that just does a sync() is possible. >'Splain me why a "fscache -writeback 0" (or something equivalent) is so >distasteful? Please, let's not debate the pros and cons of write-back >caching. Ok, ok, ok. Here is a simple patch (not cdiff, but you can do it by hand) that essentially implements write-through. I won't put it into the standard kernel (unless somebody pays me $$$ - anybody? I'm /very/ corruptible.) but you might try it out if you want to.. In the function brelse(), in fs/buffer.c: void brelse(struct buffer_head * buf) { if (!buf) return; + ll_rw_block(WRITE,buf); wait_on_buffer(buf); if (!(buf->b_count--)) panic("Trying to free free buffer"); wake_up(&buffer_wait); } One line to add, and voila. Magic. I still like the fsync() and O_SYNC ideas better, but the above is so simple anybody can try it out. DISCLAIMER: I used my usual rigorous testing techniques on the above, ie none. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: problems with the new mount(2) Message-ID: <1992Jul14.105210.6964@klaava.Helsinki.FI> Date: 14 Jul 92 10:52:10 GMT References: <1992Jul11.230357.13628@daffy.cs.wisc.edu> <1992Jul13.145414.7357@bernina.ethz.ch> <1992Jul14.053132.910@daffy.cs.wisc.edu> Organization: University of Helsinki Lines: 45 Before you flame each other to death, I'd just like to point out that the kernel interface to mount() and the actual mount() system call can (and in this case should) be totally different things. I used the new kernel-level interface because it's simple and relatively clean from a kernel standpoint, but that does /not/ mean the actual mount() library function has to conform exactly to the kernel parameters. There is precedent for this: some system calls (like readdir()) have arguments that are totally different from the user-level library interface. The mount() library would probably look something like this (you could even do bit-twiddling to get the flags to have the same meaning as in BSD, although I really doubt it's worth it): #define __LIBRARY__ #include #define __NR_sys_mount __NR_mount static inline _syscall5(int,sys_mount,const char *,device,const char *,dir, const char *,type,int,flags,void *,data) int mount(const char * device, const char * dir, const char * type, void * data) { unsigned long flags = 0xC0ED0000; /* magic number */ int result; if (data) { flags |= 0xffff & *(long * data); data += 4; } return sys_mount(device,dir,type,flags,data); } That way the library interface would be simple and automatically insert the magic numbers that mean it's using the new format. And to the person who complained about magic numbers: there is currently only two magic numbers like this in the kernel - for reboot and mount. Reboot obviously wants magic numbers (and they shouldn't even be hardcoded into the library): otherwise it would be easy for root to reboot by accident in case some user-level program gets confused. And yes, I could have made a new mount() system call, but there is not really much difference between that and the current implementation. Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: FAQ addition: (was Re: Badblocks revisited (**sigh**)) Message-ID: <1992Jul16.220318.15436@klaava.Helsinki.FI> Date: 16 Jul 92 22:03:18 GMT References: <9207160920.AA00919@optical.bms.com> Organization: University of Helsinki Lines: 48 In article unixsys@ssg.com (Rick Emerson) writes: >u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) writes: >> >> Linux does not mark bad blocks, so you have to do that. It's not really >> difficult, it is just that you need MINIX to do the job. Don't yell at >> me ... That was true of linux versions 0.10 and below: I think 0.11 already had a mkfs that did the mapping out of bad blocks (this can be confusing to minix users: in minix, you use a special program for it, under linux you just use "mkfs -c" (or "mkfs -l" if you know the bad blocks)). Linux maps out bad blocks by putting them in a ".badblocks" file in the root directory (although you can naturally rename this later) that has inode nr 2. Minix used several small files, as the minix badblocks program was too stupid to understand about indirection in an inode, so it created a inode for every 7 bad blocks (minix inodes have 7 direct pointers in them). So if you have a .badblocks file, you should be careful not to try to back it up if you are doing a full system backup: it will result in no end of read errors (not too surprisingly). Also note that linux doesn't do bad-block mapping at a device level: It's done by the filesystem. Mapping bad blocks on a lower level is complicated, and often not worth it (as most new controllers do it in hardware). > You > must > be > joking! No, this was standard practice with the early versions of linux. I hadn't written a mkfs or a fsck, so you actually needed minix to set things up. Happily, this is no longer true, and hasn't been for about 8 months or so. >Install another OS to fix this one? (Yes, yes, yes, I know Linux is >descended from Minix) Actually, "descended" is too strong a word: I just used minix as the platform I wrote it on, and that has made its mark mostly on the original filesystem layout. Minix and linux are worlds apart internally: totally different principles in all things from interrupt handling to process control and memory management. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux,comp.os.coherent Subject: Re: Are Linux executables compatable with Coherent 4.0? Message-ID: <1992Jul16.222559.16115@klaava.Helsinki.FI> Date: 16 Jul 92 22:25:59 GMT References: Distribution: comp Organization: University of Helsinki Lines: 34 In article sje@xylos.ma30.bull.com writes: >The beta version of MWC Coherent 4.0 (32 bit flat addressing for the >386+ CPU family) claims that it has SCO executable compatability for >character I/O programs at the Intel Binary Interoperatibility Level >(or whatever). MWC has gotten gcc to run allowing the production of >ASNI C applications. However, there are only a limited number (less >than 10) of officially converted applications. Given the apparently >large number of programs now working under Linux, I was wondering if >any of the Linux binaries, particularly gcc, may be run under Coherent >4.0 without modification. Also, it would be interesting if the >reverse was true. No, linux binaries won't work under Coh4.0 nor vice versa. I don't know if the actual header is a problem (linux uses the standard a.out header that gcc produces), but system calls aren't handled the same way. I personally think binary compatability is evil (or at least unnecessary) and in most cases just forces old mistakes on a new product etc (just look at DOS). And as there aren't any binaries available with the standard i386 ABI anyway that I could afford and want to run, I saw no reason to even try. [ Not to mention the fact that I haven't got any information at all on the "standard" binary interface - which makes things a bit hard to program :-) ] Of course, somebody might try to write a system call emulator that does the necessary translations, but it would probably be pretty ugly. I don't even know how a system call is handled under normal i386 unices: linux uses "int $0x80" with all the necessary info in the registers, but there are several other possibilities available (jumping through a trap-gate with or without stack copying etc), and the chances that I would hit on the same interface as other 386-unices are pretty slim. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Good comm program? Message-ID: <1992Jul17.194456.8136@klaava.Helsinki.FI> Date: 17 Jul 92 19:44:56 GMT References: <1992Jul17.142447.16334@athena.mit.edu> Organization: University of Helsinki Lines: 27 In article <1992Jul17.142447.16334@athena.mit.edu> chchen@stat.fsu.edu writes: > >3.kermit is good but no rz, sz. I have tried to use them in kermit's > command line (! rz) but it seems that rz can not find the com port > , just waiting there. The way I have rz/sz set up is to get one of the newer versions that open "/dev/tty" explicitly in rbsb.c, and change that open to "/dev/modem". After that, you can link /dev/modem to whatever device you use, and rz/sz will happily use it directly. The normal rz/sz behaviour requires the communication program to know about controlling terminals, and setting it up correctly for rz/sz. Additionally, making /tmp/rzlog and /tmp/szlog (usually symbolic) links to /dev/tty means you get the verbose output to the screen: at a kermit session I just type "^\ C" to get to the kermit prompt, and then "! rz -vv" to receive using zmodem (or "! sz -bvv xxxx" to send). After having set up things like the above, I get a nice verbose output (thanks to the 'vv' flags) of how far the down/up-load has progressed. Naturally, there are other ways you can set things up, and this just happens to be the way I use it. Having hardcoded /dev/modem to be the device sz/rz uses may not work in all circumstances (ie rz/sz won't work if you have several dial-in lines or similar), but it works for me and simplifies a lot of things. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Floppies (was Re: File system issues!) Message-ID: <1992Jul15.180004.20299@klaava.Helsinki.FI> Date: 15 Jul 92 18:00:04 GMT References: <1992Jul10.164650.2229@rs6000.cmp.ilstu.edu> <1992Jul12.104841.2039@klaava.Helsinki.FI> <1992Jul14.150258.29853@hubcap.clemson.edu> Organization: University of Helsinki Lines: 26 In article <1992Jul14.150258.29853@hubcap.clemson.edu> dawill@hubcap.clemson.edu (david williams) writes: > > I'll say one thing for the floppy driver - it's much faster than the >MS_DOG floppy. I was exceeding pissed at my 386 floppy performance, >and had pretty much given up on my controller as the problem. Not so! >Running floppy I/O under Linux is a breath of fresh air, so it's not my >hardware... It's a problem with MS_LOSS. Once more, proof that Linux >is a really nice system. This is due to the track-buffering: linux is pretty good at reading sequential data (as in tar-files etc), but performance isn't that good if you use the floppy for a filesystem (although the buffer cache does help in that case). > Anybody have an idea why MS-DOG is so slow in comparison with Linux >if the floppy drivers for Linux are in such a sad state? It's not that the driver isn't good: the linux drivers work pretty well (with the exception of some problems), and they do a lot of smart things: it's just that the actual code to do it isn't pretty. That means potential bugs are hard to find, but it doesn't necessarily mean the driver is slow. I'd like to start over on a clean slate, but it's hard to find the energy when the current driver works as well as it does. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: problems with the kernel mathcode ? Keywords: irit 3.0 modelling program with X11-Interface Message-ID: <1992Jul14.165646.14572@klaava.Helsinki.FI> Date: 14 Jul 92 16:56:46 GMT References: <1992Jul14.090231.25102@Informatik.TU-Muenchen.DE> Organization: University of Helsinki Lines: 25 In article <1992Jul14.090231.25102@Informatik.TU-Muenchen.DE> menes@Informatik.TU-Muenchen.DE (Rainer Menes) writes: > >Yesterday I complied the 0.96cpl1 kernel, and with this kernel the program >hang in all sitiations (without gdb, with gdb and stepi). If you are using a 386-387 combination, there is a bug in the IRQ13-handling code of 0.96c.pl1 - when I changed the IRQ's, I didn't remember about the (stupid IBM-imposed) special handling of the 387 errors on the AT architecture. This particular bug leads to hangups at math-errors in some circumstances. It shouldn't happen on 486 machines, although I'm not 100% sure. Other known problems with 0.96c.pl1 are: you can't use IRQ9 for the serial lines due to a typo in irq.c. And due to a thinko in serial.c, the IRQ switching of the serial lines doesn't actually work. I assume this was to be expected, as the IRQ code was totally rewritten, but it's a pity in any case: I had hoped c.pl1 would be reasonably stable. As it is, I'll have to make pl2 available soonish: I hope to get the select() code finally cleaned up before that, but I'll make the patch available again the upcoming weekend if possible. The 0.96c.pl2 kernel will contain the bus-mouse driver and the bug-fixes: if the SCSI drivers can be updated, I might do that too. No real new features. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: New Bus Mouse Driver patches for 96c-patchlevel1 Message-ID: <1992Jul15.180739.20524@klaava.Helsinki.FI> Date: 15 Jul 92 18:07:39 GMT References: <63336@hydra.gatech.EDU> <63338@hydra.gatech.EDU> Organization: University of Helsinki Lines: 12 In article <63338@hydra.gatech.EDU> gt7080a@prism.gatech.EDU (Nathan I. Laredo) writes: >I should probably mention that the mouse driver is on >banjo.concert.net as mouse96c1.tar.Z in /pub/Linux/Incoming >and should be on tsx-11 sometime or other (I sent it there >as well) in the next few weeks. He also sent it to me by mail (correct procedure), and as I was cleaning up the IRQ and select() code anyway, it went in with my changes. Expect the mouse-driver in 0.96c.pl2 (out Saturday as usual). I'll want to hear if the select() routines work for the mouse as well. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.96c second patch Summary: it's out Keywords: 0.96c patch Message-ID: <1992Jul18.205448.25947@klaava.Helsinki.FI> Date: 18 Jul 92 20:54:48 GMT Organization: University of Helsinki Lines: 92 [ This already went out to the normal linux-activists list, so if you got it that way, you can ignore this post. BTW, I have some reports that some messages from over here don't make it all the way to the US, so if you don't see this, mail me :-] The subject pretty much says it all: I've sent out the "weekly patch" and I'd be very interested in comments. As with patch1, there are some very fundamental changes in the kernel, and they might have some problems. I'd want as many as possible to test out linux-0.96c.pl2, as that has always been the best way to test out the changes. Everything works on my machine, but that doesn't guarantee it will work on other setups... The MAJOR change in 0.96c.pl2 is the totally rewritten sleep/wakeup code. That, together with the IRQ code introduced in pl1 and slightly edited in pl2, means that two very fundamental things in the linux kernel have changed in the last two weeks. The code is cleaner, easier to add devices to, and hopefully faster, but it's still a bit risky to change this kind of very low-level behaviour. Select() is now implemented using the vfs jump tables, and thanks to the better sleep/wakup interface, select() performance should be noticeably better. At least xload seems to give lower load-averages, and I hope ka9q will work better with the new kernel. Note that things like the tty code doesn't yet take full advantage of the new features the rewritten sleep offers, but I wanted to get a good testing-release out before actually tweaking all the routines to use the new interface. The IRQ routines have changed slightly, and all known bugs are fixed. While I'm most interested to hear comments about the IRQ and select/sleep/wakup code, there are a few other changes in pl2: - Swiss keyboard support. - Screen blanking now only reacts to key-presses and kernel messages: normal tty output doesn't make the screen unblank. - DOS-fs version 5 is in. It wouldn't hurt to try it out. It's somewhat alpha still, but it seems to work. mtools should be a thing of the past once the dosfs is a bit more tested. - core-file magic number, and a minor bug in ptrace is fixed - a bus-mouse is supported. I'd like to hear if it still works after I did the select() patches "blind" (I can't test it on my machine). - iopl changing is possible (but requires root priviledges): this allows access to all IO ports, as well as the interrupt flag. Don't use it unless /absolutely/ necessary: a bug in your program will most likely crash the machine if you are running with IO priviledges. It's needed for some X VGA drivers. As a result of all the changes, the diff is pretty big. Apply and build it with something like: cd /usr/src zcat linux-0.96c.patch2.Z | patch -p0 cd linux make dep make clean make Image assuming you have the 0.96c.pl1 kernel in /usr/src/linux. I've had some reports that my patches won't always go in cleanly: I know for a fact that patch1 patches cleanly (I rebuilt 0.96c.pl1 by downloading it all from banjo), so the error is in your end. Possible problems: - The VESA code in setup.S has some problems. I haven't even looked into it yet, so if it won't work for you, please either (a) use the unpatched setup.S from 0.96c, or (b) try to find the problem and tell me. (b) is preferable, of course. I'd like to have VESA support, but if the bug isn't found, I'll have to use the non-VESA version for 0.97. - The IRQ code in 0.96c.pl1 could overrun the stack if linux got un-ending interrupt requests, resulting in a re-boot. With pl2, this shouldn't happen: linux should print out something like "Recursive interrupt on IRQx. Shutting down" and simply disable the problematic IRQ line. If you see this message, I'd be very interested to hear about it (which IRQ, what devices you have, etc). - And any new or old bugs I haven't found yet. I have one report that 0.96c.pl1 has problems with the inode table, and panics on bootup with a "no more inodes in mem" report. Can anybody confirm this sighting? I haven't found the reason for it, and haven't seen it myself. I'm hoping it's an installation problem, but if anybody else sees the same behaviour, I'm SOL. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.96c second patch Keywords: 0.96c patch Message-ID: <1992Jul18.224304.19011@klaava.Helsinki.FI> Date: 18 Jul 92 22:43:04 GMT References: <1992Jul18.205448.25947@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 7 Oops. I forgot to mention that the sleep/wakeup code changes in patch2 change the kernel data structures enough to freak out 'ps' etc programs that go mucking around with /dev/kmem. It is not enough just to do a "ps U" to update the nametables: you actually have to recompile the ps package. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Termios question: Semantics of VMIN/VTIME on Linux/SunOS ? Message-ID: <1992Jul19.201601.13942@klaava.Helsinki.FI> Date: 19 Jul 92 20:16:01 GMT References: <9207151400@gandalf.moria> Organization: University of Helsinki Lines: 39 In article arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes: >michael@gandalf.moria (Michael Haardt) writes: > >> buff.c_cc[VMIN]=5; >> buff.c_cc[VTIME]=1; >> tcsetattr(file,TCSANOW,&buff); >>I am no termios expert, but this code is intended to let a >> read(file,buffer,sizeof(buffer)); >> >>read as much characters as available, max sizeof(buffer) and return >>after a short timeout if there are none. Ok? The way linux does this is (a) wait for at least one character (VMIN > 0 and VTIME > 0), (b) read as many characters as possible, with a timeout of max 0.10 seconds between any of the first 5 characters. Thus the read can return: -1: EINTR - a signal happened (but you usually don't see this: the read is mostly re-tried after the signal is handled) 1-5: linux got one character, followed by four characters within the inter-character timeout given (VTIME = 1 -> 0.1 sec). 6-sizeof(buffer): after the fifth character there was actually more data available, without any timeout. >I was under the impression that this should actually return on >either 5 characters recieved, or sizeof(buffer), or timeout.. The only thing that I have that explains this all is the SunOS manpage, so I cannot actually guarantee the above behaviour by linux is correct. Could somebody with the POSIX standard available actually check it out? Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Termios question: Semantics of VMIN/VTIME on Linux/SunOS ? Message-ID: <1992Jul21.183946.9138@klaava.Helsinki.FI> Date: 21 Jul 92 18:39:46 GMT References: <1992Jul19.201601.13942@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 60 In article arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes: >torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: > >>The way linux does this is (a) wait for at least one character (VMIN > 0 >>and VTIME > 0), (b) read as many characters as possible, with a timeout >>of max 0.10 seconds between any of the first 5 characters. Thus the >>read can return: > >Errm.. Question.. Can you think of a possible USE of this? >It dosen't seem quite logical to do it this way, it would be >much more usefull to return on either 5 chars OR timeout regardless >on the first character.. Ours is not to wonder why... Frankly, the above is what the SunOS man-pages seem to say, and as that's the only info I have on the subject, that's how linux does things. SunOS seems to be pretty close to posix, and following the man-pages has so far worked pretty well. I don't know the reasons for the POSIX behaviour, and the man-pages might be wrong (and I might even have misunderstood), but I'd rather be conforming to weird standards than have problems porting programs later on when they expect that behaviour. As I already mentioned, I'm very open to changing the behaviour: but I need to have actual "chapter and verse" from the posix standard before I start changing things. The current behaviour works with a lot of programs, and conforms to the only docs I have, so I really need some strong arguments to change it. The VMIN/VTIME arguments are currently understood by linux as (note: this info is only used when not in canonical mode): VTIME = 0 VMIN = 0 Instant return, reading as many characters as possible from the terminal. VTIME = 0 VMIN > 0 No timeout, and we return once VMIN characters have been read. We still might return before that in case of signals etc, and if there are more characters available, they will be read. VTIME > 0 VMIN = 0 This is a simple timeout-read: we wait VTIME*0.1 seconds or until at least one character has arrived. The read will not take more than VTIME*0.1 sec, not counting scheduling etc overhead. VTIME > 0 VMIN > 0 VTIME*0.1 seconds is an inter-character timer that is started after the first character is received, and restarted at each new character until VMIN characters have been received. The read() returns at least one character (again not counting signals), as the timer comes into play only /between/ characters. All the above have an upper limit of the given buffer-size: none have a true lower limit (as they can return less than VMIN characters). VMIN isn't meant to be used for packet-sized communication: it's just used to help decide when/how to accept timeouts. Can somebody please confirm if the above is actually the correct behaviour? Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Better serial throughput: another approach Message-ID: <1992Jul21.201858.11059@klaava.Helsinki.FI> Date: 21 Jul 92 20:18:58 GMT References: <2A6C23D4.5D7F@tct.com> Organization: University of Helsinki Lines: 56 In article <2A6C23D4.5D7F@tct.com> chip@tct.com (Chip Salzenberg) writes: >According to hedrick@dumas.rutgers.edu (Charles Hedrick): >>I've finally concluded that there's just too much code being >>executed per character. > >There is another way, as SCO does: > > At serial interrupt: just store the character in a queue and return. > Don't go through scheduler, just return. > > At clock interrupt: pull characters off the queues and do the rest > of the processing that is currently happening at serial interrupt > time. Then run the scheduler, _once_. > >Presto: minimum-overhead serial I/O. This is in fact how linux does it already: the problem has been to find the offending code. As I haven't actually seen the character loss, I originally thought it was either bad interrupt latency or simply too slow serial interrupt routines. After more testing (mainly thanks to hedrick), it seems the problem is actually the clock interrupt routine: it's too slow. "Why would the system care how slow the clock interrupt is?" - the reason is simple: interrupts are enabled while the serial interrupt happens, so the following can happen: serial interrupt received: handler started timer interrupt received: immediate response timer interrupt does the serial copying, returns serial handler returns. The result is that while the serial code is fast enough, it can get interrupted by the timer interrupt (which happens 100 times a second: not too surprising if it happens while the serial handler is active every now and then). The timer interrupt isn't that complicated, but it does do the copy_to_cooked routine, which can take some time. So, there are four possibilities: (a) make the serial interrupt handler atomic or (b) speed up the copy_to_cooked routine or (c) move copy_to_cooked from within the timer-interrupt to some less time-critical place and (d) rewrite the general tty handlers totally to have less need for the copy-to-cooked routines. I'm in fact looking into all four possibilities, and 0.97 will contain one or several of the fixes. One way of getting slightly better performance already is to use the patch by hedrick, which essentially speeds up copy_to_cooked by making some of the help-function inline etc. [ Note that you cannot right now use SA_INTERRUPT to install a serial handler that is totally atomic: it's still interruptible in the general IRQ handling code. I'll have to change this for the next version anyway, as the old problems with some (buggy?) harddisks are back ] Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: /dev/ttys? not responding Message-ID: <1992Jul23.103716.29243@klaava.Helsinki.FI> Date: 23 Jul 92 10:37:16 GMT References: <1992Jul22.235626.17486@ncsu.edu> Organization: University of Helsinki Lines: 24 In article <1992Jul22.235626.17486@ncsu.edu> doogie@garfield.catt.ncsu.edu (Jeff House) writes: > >I did the following: [ edited ] > >echo "ATDT5551111" > /dev/ttys0 > > [ some more editing ] Neither case dialed, and >when I did: > >cat /dev/ttys0 > >"ATDT5551111" was echoed. My modem seems not to be accepting commands. This is pretty much what should happen: hayes-compatible modems expect a carriage return ('\r') after the command, and the above just sends the normal unix line-feed instead. As the modem is echoing you, you do have a good connection to it, so things should work after correcting the above to: $ echo -e -n "atdt5551111\015" or similar. Or get kermit, and type the above in directly. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: sigaction sys-call Message-ID: <1992Jul25.114912.17913@klaava.Helsinki.FI> Date: 25 Jul 92 11:49:12 GMT References: <1992Jul25.110852.24366@fwi.uva.nl> Organization: University of Helsinki Lines: 14 In article <1992Jul25.110852.24366@fwi.uva.nl> vesseur@fwi.uva.nl (Joep JJ Vesseur) writes: > >Looking around in the include files, i came across a line that said > "Ok, I haven't implemented sigactions, but trying to keep headers POSIX" > (/usr/include/signal.h) >but in the kernel source file signal.c there is code to implement >sigaction. Is this some sort of dummy code, or is signal.h out of date and >is sigaction fully functional? Sorry: I don't write too many comments, and when I do they seem to become obsolete. sigaction() is completely implemented, and has been since 0.12 or something like that.. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: C_A_D=0 Message-ID: <1992Jul27.185353.5771@klaava.Helsinki.FI> Date: 27 Jul 92 18:53:53 GMT References: <1992Jul27.180447.28246@ifi.uio.no> Organization: University of Helsinki Lines: 38 In article <1992Jul27.180447.28246@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes: > >I have mucked about with the kernel lately (0.96cpl2). When I set the >C_A_D varaible to 0 (to avoid reboot on pressing C-A-D) (and compile, >reboot :-). After login in and executing sync I press C-A-D and the >system locks, completely... Anyone with similar experiences? Setting 'C_A_D = 0' results in init being sent a SIGINT instead of a instant reboot when ctrl-alt-del is pressed. If you have the old init that doesn't handle a SIGINT, you get a very dead system: init dies, and everything essentially locks. There are two possible solutions to this: (a) get one of the newer init packages that handle SIGINT gracefully, and do a clean shutdown. (b) apply this "patch" (or wait for my next release): in linux/kernel/sys.c, ctrl_alt_del(): ! if (task[1]) send_sig(SIGINT,task[1],1); should be: ! if (task[1] && task[1].sigaction[SIGINT-1].sa_handler) send_sig(SIGINT,task[1],1); The patch essentially checks that a signal handler is present before sending the SIGINT. That way old init packages won't be surprised. Linus PS. I'll probably make patch3 to 0.96c available sometime later this week: the main new feature is a dynamic buffer-cache. The original patches were by oreilly, but have been almost totally rewritten by me. The IRQ code has also been edited and is hopefully stable now. =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: C_A_D=0 Message-ID: <1992Jul27.191256.6181@klaava.Helsinki.FI> Date: 27 Jul 92 19:12:56 GMT References: <1992Jul27.180447.28246@ifi.uio.no> <1992Jul27.185353.5771@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 21 Never write in a patch by hand: it usually gets messed up... In article <1992Jul27.185353.5771@klaava.Helsinki.FI> I wrote: > >(b) apply this "patch" (or wait for my next release): > > in linux/kernel/sys.c, ctrl_alt_del(): > >! if (task[1]) > send_sig(SIGINT,task[1],1); > > should be: > >! if (task[1] && task[1].sigaction[SIGINT-1].sa_handler) ^^^ > send_sig(SIGINT,task[1],1); the 'task[1].sigaction' should obviously be a 'task[1]->sigaction', or it won't even compile... Linus "shamefaced" Torvalds ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: MicroSoft Bus Mouse v.s. Linux 0.96c(pl2) Message-ID: <1992Jul29.092511.18926@klaava.Helsinki.FI> Date: 29 Jul 92 09:25:11 GMT References: <1992Jul27.191720.2986@uwm.edu> <2835@ariel.its.unimelb.EDU.AU> Organization: University of Helsinki Lines: 20 In article <2835@ariel.its.unimelb.EDU.AU> rab@ariel.its.unimelb.EDU.AU (Richard Alan Brown) writes: > >I have a Microsoft InPort mouse, and it certainly doesn't work. However, >Nathan Laredo advises me that InPort mice are really just serial mice. >My InPort mouse card uses IRQ 5 and according to the docs uses port address >0x23C-0x23F, so i tried: > > % setserial /dev/tty2 0x23C 5 > >and locked up the system quite nicely! I have no idea what to do next... >any ideas ?? setserial got broken in pl1 or pl2: it locks the machine under some circumstances (actually, anything that opens a serial device that has the wrong parameters will do it). I'll make 0.97 available this weekend (dynamic buffers and the new SCS drivers), and the problem should be corrected. I'm still testing out some bug that seems to occur when memory is tight, but 0.97 should be pretty stable. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Problem with ld? Summary: 0.97 out soon Message-ID: <1992Jul30.001305.5863@klaava.Helsinki.FI> Date: 30 Jul 92 00:13:05 GMT References: Organization: University of Helsinki Lines: 42 In article negaard@aero.org (Eric Negaard) writes: > >At the time I was doing the compiles I was running X, xclock, x11emacs, and >a couple of xterm's. Free was reporting somewhat less than 1 Mb physical >memory free. So I killed off a bunch of processes and the compiles/links >started running fine. At that time, another program that I was having >trouble with started working too, so apparantly there is a real problem >with virtual memory. This is all happening with a 0.96c pl 2 kernel. There is indeed a problem with VM and disk-intensive tasks - it's a race-condition where the page-IO requests can get re-ordered, resulting in weird error results. Linking big programs is one of the better ways to see this problem. The problem manifests itself as bad user-level pages, and often results in a segmentation fault or just incorrect data. The solution is to wait 2 days or so for 0.97 that corrects it (I just /love/ finding bugs before any beta-tester does, and being able to come up with an instant fix). 0.97 also contains the new SCSI drivers, the dynamic buffer code and some other nifty and nice tricks. I don't know about serial performance, but limited tests (yes, I have actually tested something) have indicated that it's finally starting to get better. ( BTW: I won't make patches from 0.96c.pl2 -> 0.97 available unless somebody explicitly asks for them: they are going to be big. If you think you /need/ patches, mail me, and I'll do them. Maybe a couple of days late, but I'll do them ) 0.97 will likely be out Friday or Saturday, and has these changes: - The new SCSI drivers (drew & co) - IRQ code should finally be stable - faster, smaller, atomic serial interrupts: better performance - bynamic buffer-cache (original diffs by oreilly, but I rewrote them) - removed races in VM code - multiple minor changes in hd.c/floppy.c/efxfs/dosfs - hooks for different-size buffers (but it's not actually ready yet) Some things aren't there: I've gotten more patches than I could keep up with, so if your patch was only partly used or not used at all, please re-send. I haven't got time to go through archives or old mail finding things I overlooked :-( Linus ================ ================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: New root disk utils compiled with new diraddr()? Message-ID: <1992Jul31.202911.26270@klaava.Helsinki.FI> Date: 31 Jul 92 20:29:11 GMT References: Organization: University of Helsinki Lines: 38 In article corywest@rice.edu (Cory West) writes: > > Will the utils on the next release of the root disk be >compiled with the correct readdr() so that they will be able to >deal with the new ext file system? The current (0.96) rootdisk (and mcc-interim) should already be compiled with gcc-2.2.2, using the readdir() syscall. Most binaries that have been made available in the last month should be good: looking at the date-information at the ftp-sites is generally a a good indication (although not 100% sure). > I was trying to test out the >ext file system, but I don't have the resources to recompile >everything. When might we see this? When might the extfs move from >beta to production? The problem with the extended fs is now mostly a performance thing: the fs might still be changed to use bigger block-sizes for faster operation. Remy Card has shown interest, and I don't know if the final ext-fs will be compatible with the current one. Having a 4kB blocksize should speed up operations considerably, but while the kernel doesn't yet completely support different sized buffers I can't promise anything (0.97 has much code for it, but still some way to go). The buffer-code changes in 0.97 might eventually also mean the DOS interface gets faster: a 512-byte block-size is more natural for some DOS operations, so it might be possible that you'll eventually see a system that uses 512-byte buffers for msdos floppies, 1024-byte buffers for the minix fs and bigger buffers for the extended fs. The block drivers have to be made aware of the dynamic buffer-sizes etc, and I'll have to write some code to stop the mixing of differently sized buffers on the same device (which leads to madness). Right now (ie in version 0.97) only the low-level buffer-code knows about the dynamic sizes. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Birthday (was Re: Uptime found. Thanks to all) Message-ID: <1992Jul31.221520.27288@klaava.Helsinki.FI> Date: 31 Jul 92 22:15:20 GMT References: <1992Jul30.211132.20101@cc.umontreal.ca> Organization: University of Helsinki Lines: 398 In article <1992Jul30.211132.20101@cc.umontreal.ca> duperval@ERE.UMontreal.CA (Duperval Laurent) writes: > >P.S. BTW, noone answered yet: when is Linux's birthday? Let's have a >party! I couldn't for the life of me remember when it all happened, and I don't keep a diary, so I can't give you any exact dates for when linux "was born". But I did start to wonder, so I started ftp'ing around for archives of the comp.os.minix group (where I announced it), and this is what I came up with (with some editing). This is just a sentimental journey into some of the first posts concerning linux, so you can happily press 'n' now if you actually thought you'd get anything technical. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) > Newsgroups: comp.os.minix > Subject: Gcc-1.40 and a posix-question > Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI> > Date: 3 Jul 91 10:00:50 GMT > > Hello netlanders, > > Due to a project I'm working on (in minix), I'm interested in the posix > standard definition. Could somebody please point me to a (preferably) > machine-readable format of the latest posix rules? Ftp-sites would be > nice. The project was obviously linux, so by July 3rd I had started to think about actual user-level things: some of the device drivers were ready, and the harddisk actually worked. Not too much else. > As an aside for all using gcc on minix - [ deleted ] Just a success-report on porting gcc-1.40 to minix using the 1.37 version made by Alan W Black & co. > Linus Torvalds torvalds@kruuna.helsinki.fi > > PS. Could someone please try to finger me from overseas, as I've > installed a "changing .plan" (made by your's truly), and I'm not certain > it works from outside? It should report a new .plan every time. So I was clueless - had just learned about named pipes. Sue me. This part of the post got a lot more response than the actual POSIX query, but the query did lure out arl from the woodwork, and we mailed around for a bit, resulting in the Linux subdirectory on nic.funet.fi. Then, almost two months later, I actually had something working: I made sources for version 0.01 available on nic sometimes around this time. 0.01 sources weren't actually runnable: they were just a token gesture to arl who had probably started to despair about ever getting anything. This next post must have been from just a couple of weeks before that release. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) > Newsgroups: comp.os.minix > Subject: What would you like to see most in minix? > Summary: small poll for my new operating system > Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI> > Date: 25 Aug 91 20:57:08 GMT > Organization: University of Helsinki > > > Hello everybody out there using minix - > > I'm doing a (free) operating system (just a hobby, won't be big and > professional like gnu) for 386(486) AT clones. This has been brewing > since april, and is starting to get ready. I'd like any feedback on > things people like/dislike in minix, as my OS resembles it somewhat > (same physical layout of the file-system (due to practical reasons) > among other things). > > I've currently ported bash(1.08) and gcc(1.40), and things seem to work. > This implies that I'll get something practical within a few months, and > I'd like to know what features most people would want. Any suggestions > are welcome, but I won't promise I'll implement them :-) > > Linus (torvalds@kruuna.helsinki.fi) > > PS. Yes - it's free of any minix code, and it has a multi-threaded fs. > It is NOT protable (uses 386 task switching etc), and it probably never > will support anything other than AT-harddisks, as that's all I have :-(. Judging from the post, 0.01 wasn't actually out yet, but it's close. I'd guess the first version went out in the middle of September -91. I got some responses to this (most by mail, which I haven't saved), and I even got a few mails asking to be beta-testers for linux. After that just a few general answers to quesions on the net: > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) > Newsgroups: comp.os.minix > Subject: Re: What would you like to see most in minix? > Summary: yes - it's nonportable > Message-ID: <1991Aug26.110602.19446@klaava.Helsinki.FI> > Date: 26 Aug 91 11:06:02 GMT > Organization: University of Helsinki > > In article <1991Aug25.234450.22562@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: > >> [re: my post about my new OS] > > > >Tell us more! Does it need a MMU? > > Yes, it needs a MMU (sorry everybody), and it specifically needs a > 386/486 MMU (see later). > > > > >>PS. Yes - it's free of any minix code, and it has a multi-threaded fs. > >>It is NOT protable (uses 386 task switching etc) > > > >How much of it is in C? What difficulties will there be in porting? > >Nobody will believe you about non-portability ;-), and I for one would > >like to port it to my Amiga (Mach needs a MMU and Minix is not free). > > Simply, I'd say that porting is impossible. It's mostly in C, but most > people wouldn't call what I write C. It uses every conceivable feature > of the 386 I could find, as it was also a project to teach me about the > 386. As already mentioned, it uses a MMU, for both paging (not to disk > yet) and segmentation. It's the segmentation that makes it REALLY 386 > dependent (every task has a 64Mb segment for code & data - max 64 tasks > in 4Gb. Anybody who needs more than 64Mb/task - tough cookies). > > It also uses every feature of gcc I could find, specifically the __asm__ > directive, so that I wouldn't need so much assembly language objects. > Some of my "C"-files (specifically mm.c) are almost as much assembler as > C. It would be "interesting" even to port it to another compiler (though > why anybody would want to use anything other than gcc is a mystery). [ editors note: linux has in fact gotten more portable with newer versions: there was a lot more assembly in the early versions. Not that anybody in their right mind would try to port it even now ] > Unlike minix, I also happen to LIKE interrupts, so interrupts are > handled without trying to hide the reason behind them (I especially like > my hard-disk-driver. Anybody else make interrupts drive a state- > machine?). All in all it's a porters nightmare. > > >As for the features; well, pseudo ttys, BSD sockets, user-mode > >filesystems (so I can say cat /dev/tcp/kruuna.helsinki.fi/finger), > >window size in the tty structure, system calls capable of supporting > >POSIX.1. Oh, and bsd-style long file names. > > Most of these seem possible (the tty structure already has stubs for > window size), except maybe for the user-mode filesystems. As to POSIX, > I'd be delighted to have it, but posix wants money for their papers, so > that's not currently an option. In any case these are things that won't > be supported for some time yet (first I'll make it a simple minix- > lookalike, keyword SIMPLE). > > Linus (torvalds@kruuna.helsinki.fi) > > PS. To make things really clear - yes I can run gcc on it, and bash, and > most of the gnu [bin/file]utilities, but it's not very debugged, and the > library is really minimal. It doesn't even support floppy-disks yet. It > won't be ready for distribution for a couple of months. Even then it > probably won't be able to do much more than minix, and much less in some > respects. It will be free though (probably under gnu-license or similar). Well, obviously something worked on my machine: I doubt I had yet gotten gcc to compile itself under linux (or I would have been too proud of it not to mention it). Still before any release-date. Then, October 5th, I seem to have released 0.02. As I already mentioned, 0.01 didn't actually come with any binaries: it was just source code for people interested in what linux looked like. Note the lack of announcement for 0.01: I wasn't too proud of it, so I think I only sent a note to everybody who had shown interest. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) > Newsgroups: comp.os.minix > Subject: Free minix-like kernel sources for 386-AT > Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI> > Date: 5 Oct 91 05:41:06 GMT > Organization: University of Helsinki > > Do you pine for the nice days of minix-1.1, when men were men and wrote > their own device drivers? Are you without a nice project and just dying > to cut your teeth on a OS you can try to modify for your needs? Are you > finding it frustrating when everything works on minix? No more all- > nighters to get a nifty program working? Then this post might be just > for you :-) > > As I mentioned a month(?) ago, I'm working on a free version of a > minix-lookalike for AT-386 computers. It has finally reached the stage > where it's even usable (though may not be depending on what you want), > and I am willing to put out the sources for wider distribution. It is > just version 0.02 (+1 (very small) patch already), but I've successfully > run bash/gcc/gnu-make/gnu-sed/compress etc under it. > > Sources for this pet project of mine can be found at nic.funet.fi > (128.214.6.100) in the directory /pub/OS/Linux. The directory also > contains some README-file and a couple of binaries to work under linux > (bash, update and gcc, what more can you ask for :-). Full kernel > source is provided, as no minix code has been used. Library sources are > only partially free, so that cannot be distributed currently. The > system is able to compile "as-is" and has been known to work. Heh. > Sources to the binaries (bash and gcc) can be found at the same place in > /pub/gnu. > > ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled > (and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to > set it up if you want to run it, so it is not yet a standalone system > for those of you without minix. I'm working on it. You also need to be > something of a hacker to set it up (?), so for those hoping for an > alternative to minix-386, please ignore me. It is currently meant for > hackers interested in operating systems and 386's with access to minix. > > The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If > you are still interested, please ftp the README/RELNOTES, and/or mail me > for additional info. > > I can (well, almost) hear you asking yourselves "why?". Hurd will be > out in a year (or two, or next month, who knows), and I've already got > minix. This is a program for hackers by a hacker. I've enjouyed doing > it, and somebody might enjoy looking at it and even modifying it for > their own needs. It is still small enough to understand, use and > modify, and I'm looking forward to any comments you might have. > > I'm also interested in hearing from anybody who has written any of the > utilities/library functions for minix. If your efforts are freely > distributable (under copyright or even public domain), I'd like to hear > from you, so I can add them to the system. I'm using Earl Chews estdio > right now (thanks for a nice and working system Earl), and similar works > will be very wellcome. Your (C)'s will of course be left intact. Drop me > a line if you are willing to let me use your code. > > Linus > > PS. to PHIL NELSON! I'm unable to get through to you, and keep getting > "forward error - strawberry unknown domain" or something. Well, it doesn't sound like much of a system, does it? It did work, and some people even tried it out. There were several bad bugs (and there was no floppy-driver, no VM, no nothing), and 0.02 wasn't really very useable. 0.03 got released shortly thereafter (max 2-3 weeks was the time between releases even back then), and 0.03 was pretty useable. The next version was numbered 0.10, as things actually started to work pretty well. The next post gives some idea of what had happened in two months more... > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) > Newsgroups: comp.os.minix > Subject: Re: Status of LINUX? > Summary: Still in beta > Message-ID: <1991Dec19.233545.8114@klaava.Helsinki.FI> > Date: 19 Dec 91 23:35:45 GMT > Organization: University of Helsinki > > In article <469@htsa.htsa.aha.nl> miquels@maestro.htsa.aha.nl (Miquel van Smoorenburg) writes: > >Hello *, > > I know some people are working on a FREE O/S for the 386/486, > >under the name Linux. I checked nic.funet.fi now and then, to see what was > >happening. However, for the time being I am without FTP access so I don't > >know what is going on at the moment. Could someone please inform me about it? > >It's maybe best to follow up to this article, as I think that there are > >a lot of potential interested people reading this group. Note, that I don't > >really *have* a >= 386, but I'm sure in time I will. > > Linux is still in beta (although available for brave souls by ftp), and > has reached the version 0.11. It's still not as comprehensive as > 386-minix, but better in some respects. The "Linux info-sheet" should > be posted here some day by the person that keeps that up to date. In > the meantime, I'll give some small pointers. > > First the bad news: > > - Still no SCSI: people are working on that, but no date yet. > Thus you need a AT-interface disk (I have one report that it > works on an EISA 486 with a SCSI disk that emulates the > AT-interface, but that's more of a fluke than anything else: > ISA+AT-disk is currently the hardware setup) As you can see, 0.11 had already a small following. It wasn't much, but it did work. > - still no init/login: you get into bash as root upon bootup. That was still standard in the next release. > - although I have a somewhat working VM (paging to disk), it's not > ready yet. Thus linux needs at least 4M to be able to run the > GNU binaries (especially gcc). It boots up in 2M, but you > cannot compile. I actually released a 0.11+VM version just before Christmas -91: I didn't need it myself, but people were trying to compile the kernel in 2MB and failing, so I had to implement it. The 0.11+VM version was available only to a small number of people that wanted to test it out: I'm still surprised it worked as well as it did. > - minix still has a lot more users: better support. > > - it hasn't got years of testing by thousands of people, so there > are probably quite a few bugs yet. > > Then for the good things.. > > - It's free (copyright by me, but freely distributable under a > very lenient copyright) The early copyright was in fact much more restrictive than the GNU copyleft: I didn't allow any money at all to change hands due to linux. That changed with 0.12. > - it's fun to hack on. > > - /real/ multithreading filesystem. > > - uses the 386-features. Thus locked into the 386/486 family, but > it makes things clearer when you don't have to cater to other > chips. > > - a lot more... read my .plan. > > /I/ think it's better than minix, but I'm a bit prejudiced. It will > never be the kind of professional OS that Hurd will be (in the next > century or so :), but it's a nice learning tool (even more so than > minix, IMHO), and it was/is fun working on it. > > Linus (torvalds@kruuna.helsinki.fi) > > ---- my .plan -------------------------- > Free UNIX for the 386 - coming 4QR 91 or 1QR 92. > > The current version of linux is 0.11 - it has most things a unix kernel > needs, and will probably be released as 1.0 as soon as it gets a little > more testing, and we can get a init/login going. Currently you get > dumped into a shell as root upon bootup. > > Linux can be gotten by anonymous ftp from 'nic.funet.fi' (128.214.6.100) > in the directory '/pub/OS/Linux'. The same directory also contains some > binary files to run under Linux. Currently gcc, bash, update, uemacs, > tar, make and fileutils. Several people have gotten a running system, > but it's still a hackers kernel. > > Linux still requires a AT-compatible disk to be useful: people are > working on a SCSI-driver, but I don't know when it will be ready. > > There are now a couple of other sites containing linux, as people have > had difficulties with connecting to nic. The sites are: > Tupac-Amaru.Informatik.RWTH-Aachen.DE (137.226.112.31): > directory /pub/msdos/replace > tsx-11.mit.edu (18.172.1.2): > directory /pub/linux > > There is also a mailing list set up 'Linux-activists@niksula.hut.fi'. > To join, mail a request to 'Linux-activists-request@niksula.hut.fi'. > It's no use mailing me: I have no actual contact with the mailing-list > (other than being on it, naturally). > > Mail me for more info: > > Linus (torvalds@kruuna.Helsinki.FI) > > 0.11 has these new things: > > - demand loading > - code/data sharing between unrelated processes > - much better floppy drivers (they actually work mostly) > - bug-corrections > - support for Hercules/MDA/CGA/EGA/VGA > - the console also beeps (WoW! Wonder-kernel :-) > - mkfs/fsck/fdisk > - US/German/French/Finnish keyboards > - settable line-speeds for com1/2 As you can see: 0.11 was actually stand-alone: I wrote the first mkfs/fsck/fdisk programs for it, so that you didn't need minix any more to set it up. Also, serial lines had been hard-coded to 2400bps, as that was all I had. > Still lacking: > - init/login > - rename system call > - named pipes > - symbolic links Well, they are all there now: init/login didn't quite make it to 0.12, and rename() was implemented as a patch somewhere between 0.12 and 0.95. Symlinks were in 0.95, but named pipes didn't make it until 0.96. > 0.12 will probably be out in January (15th or so), and will have: > - POSIX job control (by tytso) > - VM (paging to disk) > - Minor corrections Actually, 0.12 was out January 5th, and contained major corrections. It was in fact a very stable kernel: it worked on a lot of new hardware, and there was no need for patches for a long time. 0.12 was also the kernel that "made it": that's when linux started to spread a lot faster. Earlier kernel releases were very much only for hackers: 0.12 actually worked quite well. That's all I found for 1991 - maybe it answered some questions. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Linux v. 0.97 is out Summary: new version release Keywords: 0.97 kernel Message-ID: <1992Aug1.150838.11254@klaava.Helsinki.FI> Date: 1 Aug 92 15:08:38 GMT Organization: University of Helsinki Lines: 99 [ I already sent this to the mailing-list, and it's the same release-note, so if you already saw it, you can skip this ] Linux version 0.97 is available as both a complete source-tree (linux-0.97.tar.Z) and a bootimage (bootimage-0.97.Z) on the normal ftp-sites. It's in incoming on tsx-11.mit.edu, so it will take a day or two to actually show up, but it's available right now on nic.funet.fi: pub/OS/Linux/testing/Linus/ banjo.concert.net: pub/Linux/Linus/ The nic.funet.fi-directory is under 'testing' not so much because this would be a testing-release, but because the directory-setup is in testing :-). I think 'testing' is unreadable, so you have to cd to the directory blindly. There is also a kernel-compilation README (written by Lars Wirzenius), as well as a COPYING (which is just a pointer to the GNU copyleft). The latter not because anything has changed, but because I got a few mails pointing out that the copyright of linux wasn't too clear. That also resulted in changing the '(C)'s in the source to 'Copyright'. Changes in 0.97: - The VESA-support was removed. I'd be happy to put it back once it works on all hardware. Instead of the VESA-code, I finally put in the automatic SVGA setup patches. See the top-level Makefile. - The IRQ code has solidified, and should work on all machines. Not all of the SCSI drivers use it yet, so I expect patches for that.. - Serial interrupts are handled slightly differently, and performance should be up. I've sent out a few alpha-releases, and testing seems to indicate that's actually true this time. Reactions have ranged from "nice" to "wonderful" :-) - The buffer-cache and memory management code has been edited quite a bit. ps/free etc programs that reads kernel memory directly no longer work, and even a recompilation won't be enough. They actually need editing before they work. The buffer-cache now grows and shrinks dynamically depending on how much free memory there is. Shift+PrintScreen will give some memory statistics. (Ctrl+PrSc gives task-info, ALT+PrSc gives current register values). The mm code changes removed some race-conditions in the VM code, and I also tried to make the Out-of-swapspace error less severe (better thrashing-detection etc). - The super-block code has been cleaned up. Especially the extended fs needs to be edited a bit to take advantage of the new setup, and I expect Remy Card will have a patch out eventually. - include-files have been moved around some more: there are still some names that clash with the standard headers, but not many. - Unswappable processes implemented: by default only 'init' is unswappable. This is a bit safer in low-memory conditions, as at least init won't die due to low memory. I also made killing init impossible: if init doesn't recognize a signal, it simply won't get it. Some other changes ("while (1) fork();" won't kill the machine for non-root users etc) - The new SCSI drivers are in. These make the kernel noticeably bigger, but you can leave them out if you don't want them. - The floppy- and hd-drivers print out more debugging-info in case of errors: this might be irritating if you have hardware that works, but often gives soft-errors. On the other hand, some old debugging-info was removed - notably for user-level protection errors etc. - Various minor fixes. I haven't made cdiffs (and I haven't gotten any requests for them, so I probably never will), but they would be pretty big. Things that I didn't have time for: - I wanted to rewrite the tty drivers to be more "streams-like" (ie not an actual streams-implementation, but some of the ideas from streams). I never got around to it: there was simply too much else to do. - I got a lot of patches, and some went in, others didn't. If you think your patch was important, please re-send it relative to the new version. I'd like comments on the new system: performance / clarity of code etc. 0.97 should correct all known bugs (at least the ones I know about), but I guess that's just wishful thinking. Note that the dynamic buffer-code also handles differently-sized buffers, but that the rest of the system (block device drivers, filesystem code etc) cannot yet take advantage of this - there is still some coding needed. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Compiling linux 0.97 Message-ID: <1992Aug2.195402.29445@klaava.Helsinki.FI> Date: 2 Aug 92 19:54:02 GMT References: Organization: University of Helsinki Lines: 25 In article tj2n+@andrew.cmu.edu (Tao Jiang) writes: > >When I tried compiling linux 0.97, every thing worked fine, except that >the operation speed is too slow compare to the previous version of >linux. I wrote a kernel profiling utility for this, and sent the patches (small) and a user-level program to print out results (even smaller) to the kernel mailing-list. If anybody sees this slow-down problem, and tries out the profiling code, I'd be interested to have some sample output. If you aren't on the kernel list, I can make the patches available on the net. >This morning, I tried to compile it with DRAMDISK=512 defined in the Makefile, >then error came out as: My mistake: I never tried the ramdisk code in 0.97. The fix is extremely simple (and is included in the above-mentioned profiling diffs, I think): move the #include to be the last of the include-statements. The reason is that wants some standard types defined, and they get defined in the other include-files. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: gid strangeness Message-ID: <1992Aug2.221640.971@klaava.Helsinki.FI> Date: 2 Aug 92 22:16:40 GMT References: <1992Aug2.201320.9109@ifi.uio.no> Organization: University of Helsinki Lines: 33 In article <1992Aug2.201320.9109@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes: > >Hm, this is strange (and seems to happen only on my machine??), anyone >seen anything similar? > >This happens with 0.96bpl2 and 0.96cpl2 (haven't tried 0.97 yet). It's standard, and it happens on 0.97 too. Explanation to follow... >I make a new group, 'test', give it number - say - 1000, ok, make a >file, and chgrp it to test. 'ls -l' (or 'v') correctly shows 'test' in >the group field. But not for long, suddenly (after 30 sec?) it changes >to something else, gid = oldgid%512; it seems. Which is _very_ >strange. The most remarkable thing about my machine is that it has a >aha1542 scsi disk controller. It's not the controller, it's the minix filesystem. Minix uses only an 8-bit value for the gid value of a file - so although linux internally (and the extended-fs) can handle real gids, the minix fs cannot. There was nothing I could do about it - there simply isn't any room in the minix inode on the disk. So when the inode is eventually read back, only the low 8 bits are correct. The solution is either to use the extended filesystem (which is still alpha, might change and might have bugs) or only use gid's in the 0-255 range. Another similar problem you can see with the minix filesystem is that only the modify-time of a file can be stored on the disk (for the same reason as the gid problem). So again, after the inode is read in from disk, the other times are reset (to the same time as the modification time). This problem is harder to see, and as programs seldom use the other times it's not likely to be a problem. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Am I incorrect in assuming that my root partition can be an ext fs? Message-ID: <1992Aug2.222619.1068@klaava.Helsinki.FI> Date: 2 Aug 92 22:26:19 GMT References: Organization: University of Helsinki Lines: 29 In article corywest@rice.edu (Cory West) writes: > It seems that >using bootlin and the 96c-pl2 kernel, I can't mount an extended >partition as a root partition. I have the partition marked ok in >my fstab and I can mount it if I boot from floppy, but I can't >mount it as the root partition. > Is this known and expected bahavior or should I fiddle >with it some more? I am booting with bootlin.com from DOS using >boot.sys as a multiplexer. 0.96c doesn't mount any other type of filesystem than the original minix one as root - you have to get 0.97. 0.97 should be able to mount any type of filesystem (you could even have a msdos fs as your root-partition if you are evil and perverse - but don't tell anyone or they'll whisper about you behind your back). Note that I (surprise, surprise) haven't tested the new root-mounting features. I don't see why it shouldn't work, but assuming it doesn't, please mail me about it. 0.97 also finally cleans up the 'struct super_block' information - it's no longer at all minix-specific. I got tired of hearing about it, and when liljeber noticed problems with the msdos-fs in a pre-release I decided to clean it up once and for all. So now the minix filesystem is in no way special: but it happens to be well tested, and should have no bugs (famous last words), so it's the way to go if you aren't too adventurous. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux 0.97 kernel compile problems Keywords: 0.97 kernel Message-ID: <1992Aug3.162747.25511@klaava.Helsinki.FI> Date: 3 Aug 92 16:27:47 GMT References: <1992Aug1.150838.11254@klaava.Helsinki.FI> <1992Aug3.062434.1600@uhura1.uucp> Organization: University of Helsinki Lines: 66 In article <1992Aug3.062434.1600@uhura1.uucp> bryan%uhura1@uunet.uu.net writes: >> >>There is also a kernel-compilation README (written by Lars Wirzenius), >>as well as a COPYING (which is just a pointer to the GNU copyleft). > >Where are these files? They don't seem to be included in my copy >of linux-0.97.tar.Z. If there's a kernel-compilation README, I need >to read it, since I'm having kernel-compilation problems. Lasu already sent out a copy of the README he wrote - and the COPYING file was indeed only a pointer to the GNU copyleft, so you should get that if you are interested in the copyright conditions. [ My comment in the README that the symlink from /usr/include/linux to /usr/src/linux/include/linux possibly wasn't needed was incorrect - you do need the symlink ] >>Changes in 0.97: >> >> - include-files have been moved around some more: there are still some >> names that clash with the standard headers, but not many. > >There are only three files left under include/sys: kd.h, mman.h, and >vt.h. Everything else that used to be under include/sys is now under >include/linux. This means that all of the source you pull off of the >net that includes files like and will >require additional tweaking before compiling under Linux. What was >wrong with leaving things under include/sys? The problem with include/sys was that the kernel-specific things clashed with the library things and vice versa. What 0.97 does is to move all (or at least 99%) the kernel definitions into include/linux - while this may result in problems for a while, the ides is that eventually (1.0 or so), the user-level include-files use the kernel include-files for kernel-specific things, and just add the library stuff. So when there before was a in both /usr/include and /usr/src/linux/include, I moved the kernel-specific things into - this contains the #defines and the data structures the kernel uses (and thus the library functions need in some cases). This allows me to add new #defines as new features are added, and if the /usr/include/termios.h does a #include , they are automatically updated. In the above you can put files like errno.h, signal.h etc instead of termios.h. Note that the above isn't true yet: the kernel headers probably still contain some things the user-level headers don't want and the user-level headers don't include them yet, but I hope it will be true in a release or two. >(Side note: Not all of the Makefiles use "-I/usr/src/linux/include", >if I recall correctly it was the SCSI code that tried to compile using >my 0.96c header files under /usr/include.) > >Also, struct stat is now undefined. Not unnaturally, this means the >kernel (with everything installed) won't compile. The file >include/linux/stat.h defines struct old_stat and struct new_stat, >but doesn't define either of them to be struct stat. The kernel will compile without changes, so if you have problems, it's due to the setup: make sure you have the /usr/include/linux symlink, and a reasonably new 'make' that correctly inherits the CFLAGS etc. I'll make the readme a bit more prominent next time (inside the actual tar-file), so maybe kompiling will be easy by 0.98. Or maybe not. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Help! Install linux Message-ID: <1992Aug3.173204.26700@klaava.Helsinki.FI> Date: 3 Aug 92 17:32:04 GMT References: <1992Aug3.164607.11322@njitgw.njit.edu> Organization: University of Helsinki Lines: 36 In article <1992Aug3.164607.11322@njitgw.njit.edu> shang@irss.uucp (shang wen-chung) writes: > >I've tried to install linux without success. >The boot image(bootimage-0.97) goes fine and detect the system >configuration correctly(SCSI HD, 2 FD, 2 serial line etc). >But after I insert Root(rootimage-0.96) diskett, I got the following >and system halt. It seems the root diskette is not a valid minix filesystem - make sure you used rawrite correctly on the diskette. It should be written to disk the same way the boot-disk was made. First linux tries to mount the disk using the minix filesystem - but that fails, due to a bad magic number. The result is: >magic match failed So linux continues, and tries to mount the floppy using the extended fs. Sadly, that try also fails for the same reason: >magic match failed Finally linux tries to mount the floppy as a msdos fs, and succeeds: >MS-DOS FS Rel. alpha.6 FAT 12, conv=6, check=n >No bmap suport But as there is no bmap support for 512-byte sectors, you cannot execute binaries from this filesystem. Even if there were any linux binaries on it, which I doubt. So either the floppy you give linux is a msdos floppy, or then the linux msdos-recognition routines as bad, and the floppy doesn't contain anything linux can use. Try to re-rawrite the root filesystem. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.97 slowdown (Re: .97 (new buffer allocation code)) Keywords: new kernel Message-ID: <1992Aug4.102113.14238@klaava.Helsinki.FI> Date: 4 Aug 92 10:21:13 GMT References: <1992Aug3.035648.7296@cs.tulane.edu> <5292@vtserf.cc.vt.edu> <1992Aug4.015452.26877@uniwa.uwa.edu.au> Organization: University of Helsinki Lines: 57 In article <1992Aug4.015452.26877@uniwa.uwa.edu.au> toivo@ucs.uwa.OZ.AU (Toivo Pedaste) writes: > >Well I did a test by compiling the 0.97 kernal (after a make clean) under both >0.96 and 0.97. I have a 386-40 with 8meg memory and ran the test in an xterm >on an otherwise idle machine (xclock was the only other X application running). > >0.96 kernal > 730s real 448s user 127s system > >0.97 kernal > 1521s real 449s user 166s system > >It took twice as long, I assume this was increased disk traffic (hence the >higher system time). Is there a problem with dirty disk blocks filing >up memory? The problem with the 0.97 dynamic buffer cache is that when memory gets tight, the buffer-cache is the first to go. Only after the buffer-cache has been minimized does 0.97 start to swap. Thus under conditions where there isn't too much free memory (running X and compiling), the buffer cache is actually smaller than before - on a 8MB machine the buffers in 0.96 were about 1.3MB, but in 0.97 they shrink to about 300kB when memory gets tight. And that means gcc effectively flushes the cache every time it's run - thus the slowdown. I've worked a bit on this (0.97 was the first version with dynamic buffers, after all, so I didn't expect it all to be perfectly tuned), and I've made the following changes to my new version: - swapping and buffer-cache shrinking are interleaved: under extreme circumstances linux still shrinks the buffers down to 300kB, but it tries to swap out a bit before that. - NRU (Not Recently Used) swapping algorithm with the idle-task helping the swapping algorithm find good pages. It's not a full LRU, but it does help to select the pages to be swapped. With the original 0.97 I got a time of 32 minutes for a kernel build under X11 (386-33, 8MB + 8MB swap, two xterms, syslog in a third xterm, xclock and xeyes). After the latest kernel changes the time is down to 19 minutes: clearly the above helps a lot. The original 0.97 had buffer usage around 300-800kB depending on how much memory the kernel make used up, and the new kernel had about 900-1600kB buffers (and swapped out un-needed pages more efficiently). Note that in the above test I had actually less memory when testing the new versions: the profiling-code in the new version eats up 300kB when active. But also note that the above speedup (32 min -> 19 min) might not be accurate on all machines - the changes migh not be as useful on machines with a different setup or with programs that have different memory/buffer behaviour. I'll make patches to 0.97 available this evening or tomorrow - the patches should also fix the 486 lockups that some people have experienced. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Problems with 0.97 kernel Message-ID: <1992Aug4.165748.17556@klaava.Helsinki.FI> Date: 4 Aug 92 16:57:48 GMT References: <1992Aug4.153021.24129@dfv.rwth-aachen.de> Organization: University of Helsinki Lines: 19 In article <1992Aug4.153021.24129@dfv.rwth-aachen.de> mj@dfv.rwth-aachen.de (Martin Junius) writes: >I just compiled the new 0.97 kernel and ran into the following >problems: > >- Right after the floppy disk detect message it says: > "floppy: unexpected interrupt" > >- When listing a tar archive on a floppy disk it says: > "floppy: Over/Underrun - retrying". Retrying seems to work, > the contents is listed correctly. Nevertheless these messages > are annoying. The problems aren't new - there is just some added debugging code in the floppy driver (and in the harddisk driver as well - if it gets errors, you are likely to see some debug-info printed out). The simple fix is just to comment out all the printk's in the drivers - they aren't needed, although they can be practical at times. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Signals are screwing up my tty reads. Message-ID: <1992Aug4.192759.28334@klaava.Helsinki.FI> Date: 4 Aug 92 19:27:59 GMT References: Organization: University of Helsinki Lines: 34 In article steve@Nyongwa.CAM.ORG (Steve M. Robbins) writes: > >I have a program which reads in lines from a terminal using fgets(). >Normally this means I can use the backspace key for editing, and my program >doesn't see this; it simply gets the edited line. > >Then, I wanted some daemons executed periodically, regardless of what the >user is doing, so I used alarm(). All my SIGALRM handler does is call >signal() and alarm() again. Suddenly line-editing no longer works. > >That is, it works between alarms, but as soon as the signal hits, I can no >longer backspace over what is already in the buffer. Sorry - it's a kernel bug that probably creapt in in 0.96c or so. Here is a easy fix that should clear it up (I hope - untested as usual): in linux/kernel/chr_drv/tty_io.c: function read_chan() else if (L_CANON(tty)) wait_for_canon_input(tty); should read: else if (L_CANON(tty)) { wait_for_canon_input(tty); if (current->signal & ~current->blocked) return -ERESTARTSYS; } The same bug exists in 0.97 (but no longer in my version). I'd like to hear if the above clears up the problem. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: .97 (new buffer allocation code) Message-ID: <1992Aug5.120359.16381@klaava.Helsinki.FI> Date: 5 Aug 92 12:03:59 GMT References: <1992Aug4.145621.26421@crd.ge.com> <1992Aug5.023248.1639@uniwa.uwa.edu.au> <1992Aug5.102706.15668@colorado.edu> Organization: University of Helsinki Lines: 57 In article <1992Aug5.102706.15668@colorado.edu> drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes: >In article <1992Aug5.023248.1639@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes: >> >>The 386 chip has a feature that lets you acomplish the same idea without >>any fancy schemes like that. The basic idea is that when a page is >>accessed for the first time, a bit is set in the page tables. WHen it is >>written, a different bit is set. The accessed bit will be used in the soon-to-be-made (I didn't get them together yesterday, but I'll try again today) first patch to 0.97. It's very practical, and didn't need any additional state information. While the current routine isn't a real LRU (Least Recently Used) which needs some actual calculations, it's NRU (Not Recently Used) which is a simple approximation that can do with just the one bit that is already provided by the hardware. A closer approximation to LRU would be some aging mechanism (the 386 page tables even have room for a 3-bit wide aging or somthing like that in the unused bits), and it might be worth implementing eventually. >>So the way to do this is to clear all the bits, and then cycle through >>doing. >> is bit set? >> yes -> clear it and go to next >> no -> it can be swapped, swap it and move on. This is similar to what the 0.97+patch1 algorithm does - it's simple, and while it's not perfect it works relatively well. Or at least that's the early indications from my tests. I won't be able to do exhaustive tuning of the algorithms, so the patch1 algorithm might not be perfect. We'll see. >Yes and no. When determining what pages you want out, you want to >deal with the hits for each incore page. There isn't a 1:1 >correspondance between a page in the page table, and a physical >page. Instead, two or more processes may have the same page mapped, >making the effect cumulative. It's a bit more work to actually go through the pages and take this into account, so I currently don't. But you are right: this is how it should (and will) be done. >Some one should see what times are for >looking at every page in every dirty 4M range in every address >space compared to what it takes to look at every page in physical >memory, ie using a reverse hash function. Actually, it's not a very time-critical check: it's done by the idle task anyway (which is the reason I originally made task[0] special: it just hasn't been used up till now). That way the machine does something useful even when waiting for disk accesses etc. In patch1 the algorithm just searches for non-accessed pages so that the system doesn't have to do those calculations every time it wants to swap something out. It should be relatively easy to enhance to do aging and check on the same page being used by several different processes. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: =.97 patch1 available on nic Message-ID: <1992Aug6.104732.16893@klaava.Helsinki.FI> Date: 6 Aug 92 10:47:32 GMT Organization: University of Helsinki Lines: 26 It seems all connections to Finland are down (or at least some server is acting up), so patch1 is available only on nic.funet.fi: pub/OS/Linux/testing/Linus/linux-0.97.patch1.Z I'll upload it to the other sites when I get a working ftp-connection. Patch 1 is essentially a performance-release, but it also contains some other patches: Ross Biro's tcp-ip stubs are there (but not the tcpip subdirectory: alpha-testers should know where to find that), as are the ext-fs superblock cleanups. The first header-file patch by hlu is also in there. The resulting patch is pretty big - it's also not as cleaned up as I'd like it to be. The swapping/buffer-block handling heuristics are better, but could still do with some tuning. Also, the idle task in this version doesn't do very much: it will be expanded to do some more page-table calculations. I will be unable to hack on linux for a couple of weeks (I'll still answer mails, read the newsgroup and fix bugs, but no heavy-duty hacking) due to some "circumstances beyond my control". That probably means that this patch is the last one for a while (three weeks) unless some bad bugs show up. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Groff binary problems Message-ID: <1992Aug8.104841.18911@klaava.Helsinki.FI> Date: 8 Aug 92 10:48:41 GMT References: <1992Aug7.123725.8121@vax.oxford.ac.uk> Organization: University of Helsinki Lines: 30 In article <1992Aug7.123725.8121@vax.oxford.ac.uk> tony@vax.oxford.ac.uk writes: >Dear Linux Gurus, > I'm having problems with the groff binaries from tsx. Having >installed all the bits in /usr/local/ then moved them /usr (OK, so I got it >wrong to start off with :-) I get the following error message when I try & read >any of the man pages. > >using groff -man -T ascii /usr/man/man1/gtroff.1 >I get the following on /dev/tty (not stderr !) :- > d9f2 fxxx not implemented This is printed by the 387-emulator inside the kernel: the opcode 0xd9f2 means "fptan" which isn't emulated. Thus linux sends the process a SIGILL, and groff prints >& this on stderr :- > groff: groff: Signal 4 (SIGILL == 4). As the first message is a kernel error message (and not printed by the groff binary, it automatically goes to the currently active virtual console (you can run groff in another VC, and still see the message on the console you are currently using). Either the groff binaries are statically linked with the hard-math library (in which case you either have to recompile them or buy a 387) or then your shared libraries are incorrectly set up (ie you have used libhard.2.2.2 for /lib/libm.2.2.2 at installation instead of libsoft.2.2.2). Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: patch1 blues Message-ID: <1992Aug9.080811.6566@klaava.Helsinki.FI> Date: 9 Aug 92 08:08:11 GMT References: <1992Aug9.033453.21711@athena.mit.edu> Organization: University of Helsinki Lines: 37 In article <1992Aug9.033453.21711@athena.mit.edu> Epstein@DOCKMASTER.NCSC.MIL writes: > >To compile ps-0.97 (3 Aug newer version) I had to rm .depend make >.depend (as stddef.h is in /usr/lib/gcc/...2.2.2/include/ vice >/usr/include/ as per distribution .depend did a make and make install >did a ps -U /usr/src/linux/tools/system /dev/swap this generated a new >psdatabase HOWEVER get message symbol '_main_memory_start' not found >trying to read invalid address Make sure you have removed all the old object files: main_memory_start no longer exists, and you should replace all occurences with just "memory_start". >I also get symbol '_paging_pages' not found trying to read invalid >address when execute free [just like other people] Rewrite free to use memory_start = get_kword(k_addr("_memory_start")); memory_end = get_kword(k_addr("_memory_end")); paging_pages = (memory_end-memory_start)>>12; These are constant (decided at boot-up), and will not change during a linux session. Other useful (dynamic) information is: nr_buf = get_kword(k_addr("_nr_buffers")); which tells you the current number of buffers in use, and nr_free_pages = get_kword(k_addr("_nr_free_pages")); which tells you how many free pages there are (this should be close to 0 as they should mostly be used for free buffers). Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.97 (and pl1) memory use Message-ID: <1992Aug10.073841.28831@klaava.Helsinki.FI> Date: 10 Aug 92 07:38:41 GMT Organization: University of Helsinki Lines: 32 [ I already sent this out to the mailing-list, but here goes... ] [ And yes, this is a /really/ silly bug, and I'm only glad nobody else found it first :-] There is a very silly bug in 0.97 (and pl1) which results in the dynamic buffer cache being badly used: when the buffers are grown, only half of the actual space reserved for them is used. The offending code is in linux/fs/buffer.c, in the function grow_buffers(): There is a for-loop something like this: for (i = 0 ; i+size <= 4096 ; i += size) { ..... bh->b_size = size; - i += size; } Note that i is updated twice (both at the end of the for-statement and in the for-block) which results in only every other buffer-area being actually used - half the available memory is simply ignored. The easy bug-fix is to remove either of the "i += size" statements, and I'd suggest you remove the latter one (marked with a "-" above). So if somebody wondered why there were only 3000 buffers although "free" reported that over 6MB was used, this is the reason. I didn't really look at the values that free returned until today, so I never noticed (Lars Wirzenius can tell about the time I "lost" 4MB or my 8MB memory for a week due to a programming thinko like the above. I didn't notice anything until I had to make him a 4MB version of the kernel :-) Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: unix clones for the pc abound Message-ID: <1992Aug11.091230.141@klaava.Helsinki.FI> Date: 11 Aug 92 09:12:30 GMT References: <1992Aug10.174226.20085@daimi.aau.dk> <1992Aug10.214854.17763@unislc.uucp> Organization: University of Helsinki Lines: 34 In article <1992Aug10.214854.17763@unislc.uucp> erc@unislc.uucp (Ed Carp) writes: > >I see references to minix sprinkled through the kernel, through comp.os.linux, >and through lots of the utilities. Some say that "such-and-such" utility was >ported from minix, or was derived from minix. Here there be dragons... Not really.. but read on. >According to current copyright law in the U.S., a derivation of a copyrighted >program (like the minix kernel, file system, or utilities) made without >permission of the copyright holder is a violation of copyright law. So, either >the linux kernel and utilities need to be 'sanitized', or someone's got to >get assurances from Prentice-Hall that someone won't get sued for what is called >"derivitive copyright infringement". The minix kernel is well-documented ("OS design and implementation" by Tanenbaum) and linux hasn't really got too much to do with minix anyway. Although I have called linux a "minix-clone", it's no longer true in any way, and never meant linux used very many ideas from minix. It just looked more like minix-386 than any other OS. Note the past tense: now even that isn't true (I'd say it's closer to either a "real" sysv or bsd box than to minix). There are a few things in the kernel that have been influenced by minix: the original minix filesystem is the main one. Even that is a total rewrite (and much better it is, if I may say so :-) and just keeps the old physical layout on disk. Things like select() and VC's were also originally influenced by their respective minix-patches (*). Linus (*) Note: these aren't even part of minix, but are available as patches to minix written by others. Even if linux had used their code instead of just their ideas, P-H has nothing to do with them. ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: root disk vs. mj disk, also hd.c patch Message-ID: <1992Aug12.225636.5039@klaava.Helsinki.FI> Date: 12 Aug 92 22:56:36 GMT References: <1992Aug12.011334.17155@ultb.isc.rit.edu> Organization: University of Helsinki Lines: 37 In article <1992Aug12.011334.17155@ultb.isc.rit.edu> axi0349@ultb.isc.rit.edu (A.X. Ivasyuk ) writes: > > >First of all, how do you get the executables to be so tiny on the root disk >and the mj distribution? I can't get mine under 9K, even a 'hello, world' >program. I'd like to be able to squeeze my 80MB drive to the max. >It can't be just the -O flag on gcc. By using shared libraries, and the "-N" flag, and stripping the result you can often make trivial binaries that are much less than 9kB. BUT they won't demand-load nor share pages, so it's worth it only if the binary is truly small. Using "-N" on bigger binaries will result in bad performance and memory waste when running it. > [ Q two deleted ] >Third, where is the one-line patch to hd.c (0.97) that everyone has been talking >about? I think I missed it on the net. Could someone send it to me, please? >(I already applied patch1 and the buffer patch, and it did improve performance >noticeably, esp. patch1 - Thanks Linus!!!) It's not to hd.c but to linux/fs/buffer.c - in the function grow_buffers(). 0.97.pl1 has code that looks something like this: for (i = 0 ; i+size <= 4096 ; i += size) { bh = get_unused_buffer_head(); .... - i += size; } As you can see, 'i' is updated twice ('i += size' both inside the for-loop and as the terminating expression), resulting in using only half the available space in a page for buffers. The fix is to remove the line I have marked with a "-". The above simple fix results in much better free memory utilization, and a marked improvement in performance under some circumstances. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux history... Message-ID: <1992Aug13.095315.18548@klaava.Helsinki.FI> Date: 13 Aug 92 09:53:15 GMT References: <1992Aug3.003404.6928@athena.mit.edu> <1992Aug3.165201.26088@klaava.Helsinki.FI> <1992Aug12.173725.21885@news.uni-stuttgart.de> Organization: University of Helsinki Lines: 14 In article <1992Aug12.173725.21885@news.uni-stuttgart.de> haible@izfm386i.fertigungstechnik.uni-stuttgart.de (Pascal Haible) writes: >In article <1992Aug3.165201.26088@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes: >[...] >> >>Linus is currently about 22 years and 7 months young. He speaks > ^^^^^^^^ >That is already well (?) known - at least to kernel source readers >-- or did he harcode in his girl friend's birth day? >(hint: it's no use grep'ing for 1969 or 1970, it's a bit hidden) No, it's my birthday, and I'm surprised anybody found it. I thought I had hidden it well enough :-). And I'm not giving hints. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux CDROM (Was stabilizing Linux) Message-ID: <1992Aug13.095529.18687@klaava.Helsinki.FI> Date: 13 Aug 92 09:55:29 GMT References: <3284@ra.nrl.navy.mil> <1992Aug12.020246.22166@wimsey.bc.ca> <1992Aug12.164546.13304@crd.ge.com> Organization: University of Helsinki Lines: 18 In article <1992Aug12.164546.13304@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes: >In article <1992Aug12.020246.22166@wimsey.bc.ca>, bhenning@wimsey.bc.ca (Bill Henning) writes: >| 3.75Gb/process would be great! I am not likely to need that ofcourse, nor will >| I likely have a swap partition much greater than 10-20Mb, but fewer limitations >| are allways welcome. >| >| Now if the number of processes are also increased from 64 to say 1024 that would >| be great! (yes, I can see running out of 64 processes) > > I can see running out of 64 processes a lot faster than running out of >64MB address space. I certainly am not running that much memory and >swap. The things are related: the 64 process maximum will be gone the same day the 64MB limit is gone. It will just take a bit of coding on my part, so don't expect it tomorrow.. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Why GNU cp is flakey under Linux Message-ID: <1992Aug13.132338.8532@klaava.Helsinki.FI> Date: 13 Aug 92 13:23:38 GMT References: <1992Aug12.060338.24805@ennews.eas.asu.edu> <1992Aug12.063534.4178@muddcs.claremont.edu> Organization: University of Helsinki Lines: 23 In article jrs@world.std.com (Rick Sladkey) writes: > >An examination of the source code shows that GNU cp only performs this >optimization if it thinks that the original file also had holes. The >way GNU cp determines this is by comparing the number of blocks used >with the actual file size. Furthermore, it only does this when it is >compiled without ST_BLOCKS_MISSING defined. Note that the kernel is >created by build and does not have any holes. Yes, but GNU cp looks /only/ at the st_blocks field, and seems to ignore st_blksize altogether, assuming it's a constant (usually 512). Or that's what it looks like when just taking a quick look at the source. And as the current linux kernel happens to use st_blksize = 1024 (and thus also st_blocks is only half of what GNU cp seems to expect), the test doesn't work very well. The result being that GNU cp creates holes even if there were none in the original image. I'll probably change the default st_blksize to 512 - easy enough to change the math in linux/fs/stat.c, and it seems that's what some programs expect. Programs which understand about st_blksize shouldn't care one way or the other. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: executables in linux Message-ID: <1992Aug13.133700.9139@klaava.Helsinki.FI> Date: 13 Aug 92 13:37:00 GMT References: <1992Aug12.225538.16085@usenet.ins.cwru.edu> Organization: University of Helsinki Lines: 23 In article <1992Aug12.225538.16085@usenet.ins.cwru.edu> mdr4@po.CWRU.Edu (Mark D. Rutherford) writes: > >I'm currently running linux .95. Several times now, I've FTP'd >something, tar'd it to floppy, and then untar'd from linux, >and tried to execute what I've untar'd. I get the message, >"Cannot execute binary file" The directory listing for the file >says that it's executable, and it's docs say it's executable. >I'm sure it's something simple that I'm missing. Can anyone help? While I have tried to keep each new kernel backwardsly compatible (ie running most old binaries, excepting things like ps and in some cases gdb), it's /not/ the case the other way around - binaries compiled with a new compiler may not work on an older kernel. There have been several changes in this direction: the header information changed somewhere along the way (the old headers were still accepted, but old kernel versions didn't accept the new headers) and new features (extended stat structure etc) have made binaries unrunnable on older kernel versions. So the answer is to upgrade your kernel: if possible all the way to 0.97.pl1 + the one-line patch due to performance reasons, but 0.96c or similar should work very well for your needs. Linus ================ ================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: The Third Degree Message-ID: <1992Aug14.205408.13958@klaava.Helsinki.FI> Date: 14 Aug 92 20:54:08 GMT References: <1992Aug13.124939.16680@kth.se> <7gh1Hm#z&8@atlantis.psu.edu> Organization: University of Helsinki Lines: 28 In article <7gh1Hm#z&8@atlantis.psu.edu> bairstow@copland.psu.edu (Steven Bairstow) writes: >In article <1992Aug13.124939.16680@kth.se> d88-jwn@blofeld.nada.kth.se (Johan W}hlin) writes: >>bairstow@copland.psu.edu (Steven Bairstow) writes: >>: ... >>: - Has anyone noticed free inodes being left around? I think >>: halt/shutdown is doing it. (This is what I was trying to figure >>: out when it crashed.) >>Yes I've been having this problem at least with reboot >> > >Okay, so does anyone know where the code is for these programs so I can take >a look at them, or who the author is? I doubt it's either reboot or shutdown that results in the fsck errors: what you are probably seeing is a normal result of the filesystem setup under unix. I assume the problem is that fsck reports "inode XXX marked in use: no file uses it" and "block XXXX marked in use: no file uses it". This can happen if you install a new version of a running program (like 'init') and reboot. The old 'init' is removed from the directory tree, but as it's still in use, neither the inode nor the blocks are actually reclaimed until the program is exited. And in many cases (like /bin/sh or init or update), the program is never exited until the reboot has happened. "fsck -a" should clear up the problem - or you should be more careful when rebooting with "deleted" programs still running. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux Standards (was: Stabilizing Linux) Message-ID: <1992Aug16.073340.11418@klaava.Helsinki.FI> Date: 16 Aug 92 07:33:40 GMT References: <1992Aug6.125441.22427@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 43 In article danielce@mullian.ee.mu.OZ.AU (Daniel AMP Carosone) writes: > >May one presume that if Linus has any objections to what someone is >doing with his work (and, by proxy, the work others have contributed) >he will make them known and clear? If he does have some objection, and >that is not heeded, he is free to change the terms of the License for >later releases if he deems it necessary. Well, I've answered this by email and earlier in the newsgroup, but I guess it won't hurt to say it once more: I have no objection whatsoever to any commercial use of linux that abides by the copyright. Not only because I wouldn't have a legal leg to stand on, but simply because there isn't any point in it. I'm not making any money off linux, so I cannot lose anything by letting others do it - it's not as if they were competing in the same market-place. Also, if people sell linux, it certainly won't hurt the "free" status of linux: it won't make all the free releases go away. So there isn't really anything to get excited about - a commersial linux won't hurt the linux users in the slightest, and might make linux available to people that otherwise didn't have the possibility of getting it. The earliest versions of linux had a more restrictive copyright: any commercial activity was prohibited by it. That was mostly due to (a) an overreaction to the price I had to pay for minix ($169 may not be much, but it's still more than I can afford: I'm still paying monthly installments on my machine) and (b) protection: linux wasn't well-known then, and I didn't think it was ready for commercial use anyway. (a) is silly, (b) went away with 0.12 - the copyright essentially changed when I got the first query about selling linux (with just a small delay to make sure there were no objections from people that had made patches available. There weren't). And as to the price: it doesn't really matter. If somebody wants to make linux availabe for $ 995.95 ("special price just for you, amigo"), I'd certainly be interested to hear how well it sells, but it won't bother me. And bickering over whether $60 is too much is silly: people buy it if they feel it's worth it. Actually, a nicely priced product may sell better than a cheap one: it's illogical, but some people feel that a product cannot be very good if it's cheap. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: a patch for free in the ps-0.97 package Message-ID: <1992Aug16.114537.9026@klaava.Helsinki.FI> Date: 16 Aug 92 11:45:37 GMT References: Organization: University of Helsinki Lines: 14 Just in case anybody wonders: yes, the next patch will again break all programs (well, most of them) that read kernel memory directly. In fact, some things, notably the command line snooping that 'ps' does and the page-counting ("ps m") will break totally: they have to be rewritten, and will need kernel support. The reason is that /dev/mem is no longer able to read the data in other processes: the memory management has changed to use different page tables for each process. I either have to implement some kind of /proc filesystem or support some "get_ps_info()" system call - the get_ps_info() way is easier, but a /proc fs might be a good idea and is more general. It will have to wait for 0.98 or so, though: 0.97.pl2 won't have a good ps interface. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Whining...I don't want to hack on the kernel Message-ID: <1992Aug18.062556.6342@klaava.Helsinki.FI> Date: 18 Aug 92 06:25:56 GMT References: <1992Aug12.225538.16085@usenet.ins.cwru.edu> <1992Aug13.133700.9139@klaava.Helsinki.FI> <1992Aug18.011305.27223@access.usask.ca> Organization: University of Helsinki Lines: 20 In article <1992Aug18.011305.27223@access.usask.ca> dzubin@skorpio.usask.ca (Thomas Dzubin) writes: > >Sorry if this is sacreligious, but I DON'T WANT TO HACK THE KERNEL. It >would be absolutely *wonderful* if someone (ANYONE!?) would put the >binary of 0.97.pl1 somewhere FTP-able. It's a valid gripe, and I'll probably make a binary available when I release patch2 (this weekend). patch1 was a very hurried release: I wouldn't have released it if it wasn't for the fact that I wanted to hear comments about the speed-up (if any). As it turned out, patch1 is perfectly ok (especially after the 1-line patch), and doesn't have any more problems than any other release, but I wasn't sure when I made it. There still seems to be some problems with 0.97.pl1: the buffer-cache corruption is the worst one. I haven't seen it myself, and it seems to be a SCSI problem, but I'm not sure. I'll probably try the test-program somebody posted if I can find the disk-space for it. I doubt the problem will be fixed by patch2: especially if I'm unable to see it. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: A question about Kernel system call mechanism Keywords: linux, kernel, system call Message-ID: <1992Aug20.122051.24901@klaava.Helsinki.FI> Date: 20 Aug 92 12:20:51 GMT References: <1992Aug19.174117.21233@ramsey.cs.laurentian.ca> Organization: University of Helsinki Lines: 102 In article <1992Aug19.174117.21233@ramsey.cs.laurentian.ca> ron@ramsey.cs.laurentian.ca (Ron Prediger [Velociraptor]) writes: >I am relatively new to Linux and have been examining the kernel source. > >1) Does anyone know how linux passes parameters from the user process to the >kernel service routine ? Below is what I think is happening and where I >am confused. > >It appears that system calls are handled using interrupt or trap gates >resident in the Interrupt descriptor table (IDT). From reading the Intel >386 ref. manual I understand that a stack switch occurs automatically when >a less privileged process accesses a gate for a more privileged subroutine. Correct so far... >What I can't see is how the kernel service routine gets the system call >parameters (ie. addresses, etc) from the user process. Is there code >somewhere which copies these parameters from the original (level 3) stack to >the more privileged (level 0) stack ? If linux had used call gates to >implement system calls, the parameters would automatically be copied to the >privileged routine's stack by the 386. (This automatic >copy of parameters does not occur when referencing interrupt/trap gates.) I didn't like system call gates: they are too complicated for my taste (besides, you have to know how many arguments to copy, or have a specific system call gate for each type of argument: maybe not a bad idea, but...). Anyway, things are easier than you make them out to be: the arguments are simply passed in the normal registers. Passing arguments in the registers allows you 6 (32-bit) direct arguments (not counting %eax, which is used to tell which system call you want handled), and more if you simply set up a pointer to a block in user space. And the beauty of it all is that they are automatically put on the stack in as arguments to the system calls when the registers are saved - see the file linux/kernel/sys_call.S, which saves all the necessary state information. It's the simplest and fastest way I could find: linux doesn't even save the state in some special task-structure like other unices seem to do, but just leaves the regs on the stack, ready for popping when the process returns from the interrupt. >2) It appears that Linux is making use of segment registers (FS,GS) and the >LDT/GDT to transfer the actual data (ie. from a read system call) between >user and kernel address spaces. Is this observation correct ? Actually, only %fs is used: it points to the user-space segment when in a system call. Thus linux never needs to check any bounds when copying from/to user space: it's automatically handled by the hardware. The get_fs_XXX() and put_fs_XXX() (XXX=byte, word, long) inline functions can be used to transfer bytes from/to user space, and memcpy_tofs() or memcpy_fromfs() can be used to move bigger blocks between kernel and user segments. What happens at a system call is roughly: user space: - load the arguments into registers (%eax contains the system call index, %ebx... contain the parameters) - do an "int $0x80", moving to kernel mode: kernel space: - clear the direction-flag, as gcc assumes this - save the system call number: a negative number means the interrupt was caused by a hardware IRQ or trap. - save all the segment registers - save %eax (which happens to be the same number we saved earlier if this is a normal system call) - save the other registers: they automatically form the stack frame for the system call. - call the appropriate system call handler by indexing the appropriate table with %eax. The handler does it's stuff - it /can/ change the stack frame if it wants to, and thus return information in any registers it wants to, but that is really discouraged, and all system calls currently just return their result in %eax as part of their normal return. - check if there were any signals, and change the return stack (both in kernel and user space) appropriately if so, invoking the signal handler instead of returning directly. - pop all the saved registers, and do an iret, returning to user mode. While the system call runs, the %ds and %es registers point to kernel data space, and %fs points to user space. But the system calls may change %fs for their own needs: for example symbolic links result in changing %fs to kernel space for a while as the name is parsed directly from the kernel buffers instead of from user space etc. Note that normal faults/traps and IRQ's do essentially exactly the same, except for "fast" IRQ's, which just save a minimal amount of information and don't do the signal checking (used by things like the serial handlers). Also, they naturally haven't got any "system call number", but have their own routine that is called after the stack is set up. As to the GDT: the GDT contains just two normal segment entries: GDT[1] is the kernel code segment descriptor, and GDT[2] is the kernel data descriptor. The rest of the global descriptor table is filled with TSS and LDT descriptors. The local descriptor tables normally contain just the user-space code/data descriptors in LDT[1] and LDT[2], but it's flexible enough to be extended if something wants to have more segments in user space (I think the xenix emulator uses this, although I haven't looked at the code yet). Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Paying off Linus' PC (was: Linux Standards) Message-ID: <1992Aug21.065950.8463@klaava.Helsinki.FI> Date: 21 Aug 92 06:59:50 GMT References: <1992Aug16.073340.11418@klaava.Helsinki.FI> <1992Aug18.070709.16015@trl.oz.au> <1992Aug19.162616.3357@news.acns.nwu.edu> Organization: University of Helsinki Lines: 39 I hate to follow up to a thread that might actually be profitable for me, but I felt I had to clarify a few points - especially if there are new linux users out there reading the thread. If people feel they want to send me money (indirectly or directly) as a token of appreciation, that's very much ok by me (surprise, surprise), but a token of appreciation is all it is going to be. Yes, I'll be able to pay off my machine more quickly or even get a bigger harddisk or whatever, but sending me money won't get you any better service - this is definitely not a "registration fee" or anything like that. The above just means that (a) even if you don't send any money I won't mind in the least that you use linux, and when I answer questions etc I won't check if you sent me money first. And (b) even if you sent me money, any features you propose/want will get no extra priority. In fact, trying to make me feel guilty over money ("after all, I paid you $20 for this") is likely to get the exact opposite reaction. Finally, I won't give any guarantees of what the money will be used for: if you add some kind of message giving preferences ("use it to pay off your computer"), I'll naturally follow them within reasonable limits, but I might just use them to pay off my "beer&pizza"-debts (*), which might be against your religion or whatever. So, the result of all this? If somebody thought I was despairing about my monthly payments, that's not true, and frankly, I'll get the computer paid off even if nobody sends me a cent, even if it might take me a bit longer. Also, there are others that have contributed to linux, and I won't give them anything (not because I'm a selfish bastard, but simply due to practical reasons). If any of the above reasons made you decide I don't really need the money, I just ask you not to mail me about it. I /don't/ want to know about any money I might have gotten, but didn't. Linus (*) Yes, beer is reasonably costly over here in Finland, but no, my debts aren't really that big. Quite small, in fact, considering.. ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: A technical question on CONTEXT (TASK) SWITCHING by the Kernel Keywords: task switch, context switch, task state segment, kernel Message-ID: <1992Aug21.072548.10633@klaava.Helsinki.FI> Date: 21 Aug 92 07:25:48 GMT References: <1992Aug20.164928.24749@ramsey.cs.laurentian.ca> Organization: University of Helsinki Lines: 80 In article <1992Aug20.164928.24749@ramsey.cs.laurentian.ca> ron@ramsey.cs.laurentian.ca (Ron Prediger [Velociraptor]) writes: >Here is another technical question about the Linux kernel. Context >switching in particular. Ok, more answers... > #define switch_to(n) {\ > struct {long a,b;} __tmp;\ This just fools gcc to get 8 bytes of space on the stack, so that we don't have to get them anywhere else.. > __asm__("cmpl %%ecx,_current\n\t"\ > "je 1f\n\t %ecx is set up with the task we want to switch to when we enter the inline assembly statement, so this is obviosuly testing whether we are trying to switch to the current task, in which case nothing is done. Besides being an obvious optimization, I don't think the 386 allows a tss-jump to the current task (but not having my books around me, I can't check). > "movw %%dx, %1\n\t"\ This just moves %dx (which contains the tss-selector) into the word at __tmp+4. So ___tmp looks like this: __tmp+0: undefined long __tmp+4: tss-selector word __tmp+6: undefined word > "xchgl %%ecx,_current\n\t"\ This exchanges %ecx and 'current' - %ecx will contain the task we are now executing in, and 'current' will contain the task we are just about to jump to. > "ljmp %0\n\t"\ This does the actual task switch: we do an indirect long-jump to __tmp. This is also the reason we updated just the word at __tmp+4: a long jump to a new tss-selector will ignore all other values. It will automatically jump to the place indicated by the tss segment. > "cmpl %%ecx,_last_task_used_math\n\t"\ Yes, this looks illogical: we just did an unconditional jump, and this should never be reached. Right? Wrong. The ljmp will return once some other task does it's own ljmp to this task. Now %ecx contains the current task, so we check if this is the task that used the math coprocessor last... > "jne 1f\n\t"\ > "clts\n"\ ...in which case we can clear the TS flag, giving better math-performance. Due to these three lines, linux never saves math state unnecessarily. > "1:"\ > "::"m" (*&__tmp.a),"m" (*&__tmp.b), \ This just sets up %0 - pointing to '__tmp', and %1, pointing to '__tmp+4'. > "d" (_TSS(n)), "c" ((long) task[n]) \ %dx contains the tss-descriptor for the task we want to switch to, and %ecx contains the task-pointer of the task we want to switch to. > :"cx");\ And this just tells gcc that %ecx is changed by the inline-asm. That's it: 8 lines of assembly does the linux context switch with math-state optimizations. Note that newer sources should have a cli-sti pair around the "xchg %%ecx,_current ; ljmp %0", so that 'current' is always up-to-date, even when running under interrupts. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: shared libs - can everyone be happy with this? Message-ID: <1992Aug21.075538.12640@klaava.Helsinki.FI> Date: 21 Aug 92 07:55:38 GMT References: <1992Aug17.152210.23427@riacs.edu> <1992Aug18.023010.6841@colorado.edu> Organization: University of Helsinki Lines: 27 In article ted@nmsu.edu writes: > >writable code segments or executable data segments are _very_ >important to programs that would like to do dynamic loading. > >of these two options, the second is preferable. Right now, linux accepts both: early versions of linux didn't allow executable data-segments (the code segment was only as long as indicated by the executable header), but I changed that as gcc-2 actually assumes data space is executable (it can build small functions on the stack). Another reason was actually to get 'crashme' to run: without an executable data-segment crashme won't run at all (without modifications). And while it might sound weird to change the kernel to /help/ crashme, that's what I did. After all, the idea of crashme is to test whether a system is stable, and if crashme fails for the silly reason that it cannot execute the code it has just set up, it's not anything to brag about. The fact that crashme /still/ seems to fail despite being able to try, is a good thing (tm). Writable code might go away eventually: there is no longer any good reason for it now that the standard library should be well-behaved. But I'm not in any hurry about it: if somebody /wants/ to write self-modifying code, maybe it should be permissible. I don't dislike goto's either. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: problem compiling 0.97pl1.5 with gcc2.2.2d Message-ID: <1992Aug22.200046.25400@klaava.Helsinki.FI> Date: 22 Aug 92 20:00:46 GMT References: <1992Aug22.164625.772@rock.concert.net> Organization: University of Helsinki Lines: 35 In article <1992Aug22.164625.772@rock.concert.net> cole@concert.net (Derrick C. Cole) writes: > >Using the 96c bootimage, and after installing gcc2.2.2d and the 0.97 source >and patches, I am able to compile the kernel sans problem. > >However, after the unix socket init, I get an unstoppable list of > >[ ...lots of error stuff deleted... ] >kernel panic: no free inodes in mem >[ ...lots of error stuff deleted... ] Sounds like the infamous problem with shoelace and a kernel image with holes in it. The fix is either not to use shoelace, or make sure /vmunix (or whatever you call it) has no holes. The latter can be done by using "cat /usr/src/linux/Image > /vmunix" instead of using 'cp' (or you can use 'dd' or any number of other things). While I'm orating, I might as well mention that 0.97.pl2 will be out tomorrow: it contains mostly the memory management rewrite, but also has some bigger vfs patches (mostly with symbolic links, but also some general fixes). The changes will mostly not be seen on a user level: some error-codes have been corrected, and linux gives each task 3GB address space, but normal programs won't notice anything. The memory management cleanup also allowed a clean vm86-mode, so that's in. pl2 is relative to (unpatched) pl1, so people who have applied the 1-line fix will get patch errors. Also, while I haven't been totally out of touch, I've not answered all my mail (or answered very tersely) the last weeks, due to work. I also haven't had time to check out all the patches I've gotten etc. I should have more time for linux the upcoming weeks, so hopefully I'll try to catch up a bit. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: linux-0.97 patchlevel 2 Message-ID: <1992Aug23.221741.6989@klaava.Helsinki.FI> Date: 23 Aug 92 22:17:41 GMT Organization: University of Helsinki Lines: 56 As promised, 0.97.pl2 is out today (well, over here it's already tomorrow, so I guess I'm 35 minutes late. Naughty, naughty). Right now, the patch (and full source for those that don't like to patch up the system) is available at "nic.funet.fi: pub/OS/Linux/testing/Linus", but I'll try to put it on some other sites as well if I'm able and energetic enough. Probably tomorrow - together with a binary for those that aren't willing to comple the kernel on their own. 0.97.2 has mostly my mm/fs patches, along with some relatively minor diffs by others (including file locking by Doug Evans). User-level changes are minor: but the mm has changed a lot, and the vfs routines have been changed to keep track of the error-messages a bit better. Also, the vfs-interface to "follow_link()" changed slightly: people who are making filesystems should look at the changes (but they are relatively minor, and shouldn't result in any problems - both the extended fs and minix fs needed just a simple change in their respective symlink.c files). The mm changes /might/ lower performance slightly, as the paging TLB's are now flushed at every task-switch due to the new system, but I doubt it's noticeable. The other performance changes (dynamic buffers etc) in 0.97(.pl1) should overshadow that particular problem. I hope this release means that these kinds of low-level rewrites aren't needed for a while: the last couple of releases have changed some very fundamental things. Nothing seems to have suffered too badly, but I'd be happier if it all got tested more thoroughly. Anyway, discounting the ps/free etc suite of programs, everything I have tried has worked flawlessly despite the big kernel changes. I'm still worried about the reports about messed-up buffers, but have been unable to reproduce the problem, and nobody has so far disillusioned me about my guess that it's a problem with the SCSI code (which at least gives me an excuse for not doing anything about it :-). Other problems include at least one report of spontaneous re-booting, which is totally inexplicable, so I'm blaming hardware once more until I can get better data on the thing. As to patches sent by others: 0.97.2 contains very little of that kind of code. I've been too busy either working, or implementing my own changes that I have simply ignored them for the most part. Remind me (or resend them relative to the new kernel) if you have a patch that is still needed. There is one new system call: 'vm86(struct vm86_struct * info)'. It's not ready for general use yet - it works, but will probably need some tweaking before being practical. But supporting a virtual 86 mode was so easy after the mm rewrite that I felt it was worth implementing: the vm86 code is less than 50 lines of C right now. Linus PS. The bright spot of the week goes to "The Oxford Beer Trolls" - all UK inhabitants should probably be locked into some (big) mental institution and TOBT should probably have a wing of their own, but thanks to them linux can now call itself "beerware" :-) ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Suid/sgid Message-ID: <1992Aug26.075014.9277@klaava.Helsinki.FI> Date: 26 Aug 92 07:50:14 GMT References: <1992Aug25.230907.10073@utstat.uucp> Organization: University of Helsinki Lines: 21 In article <1992Aug25.230907.10073@utstat.uucp> rafal@utstat.uucp (Rafal Kustra (summer student)) writes: >Perhaps this should be posted to other group >but I only have time to read this one + some local >ones ;). >OK, here is the beef. >Either I don't understand the concept of suid/sgid >(**very** possible) or there is something wrong. >Say root creates a script like follows: > cat $* >and sets it suid. >Now normal user could cat any r--..... >file with it, right? You aren't misunderstanding the concepts, but suid only works on actual binary executables, not shell (or any other kind of) scripts. The reasons are security, security and security. It /may/ be possible to make a suid shell script secure, but it's so easy to make them a (non-obvious) security hazard that it's definitely a bad idea to allow them. So linux ignores the suid/sgid bits when executing scripts. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97p2 Message-ID: <1992Aug28.230526.7253@klaava.Helsinki.FI> Date: 28 Aug 92 23:05:26 GMT References: <1992Aug28.123817.20350@csd.uch.gr> Organization: University of Helsinki Lines: 50 In article <1992Aug28.123817.20350@csd.uch.gr> kermits@pasifae.cc.uch.gr (Aggelos Keromyths) writes: >I just tried 0.97p2 from the disk drive and it seemed to me a lot > slower than 0.97 (no patch at all!!!)....When i did an `ls` it > started reading the drive,then stopped,then again reading and finally > presented the directory...but it was SLOW.... >What could be the problem ? Hmm. I'd like to hear more about the problem - especially if you can pinpoint it more closely (ie having used 0.97, 0.97.pl1 and now pl2) to a specific patch. As most people said 0.97.pl1 was fast, I'm assuming it's specific to patch2, but I'd like to have some confirmation before I start looking into the problem. If it's patch2, the problem is probably the changed mm code: having different page tables for each process might be costlier than I thought. The old (pre-0.97.pl2) mm was very simple and efficient - TLB flushes happened reasonably seldom. With the new mm, the TLB gets flushed at every task-switch (not due to any explicit flushing code, but just because that's how the 386 does things when tasks have different cr3's). I can optimize things a bit - it's reasonably easy to fake away some of the TLB flushes by simply forcing the idle task to always use the same cr3 as the last task did (as the idle task runs only in kernel memory, and kernel memory is the same for all processes). So, I'd be interested to hear if this simple patch speeds linux up at all: - in linux/kernel/sched.c: schedule() - change cli(); switch_to(next); to cli(); + if (!next) + task[0]->tss.cr3 = current->tss.cr3 switch_to(next); ie just add the one if-statement. If the above makes a difference, I'd like to hear it, and I'll put it in the standard kernel. I'd also like to know what kind of machines the slowdown is most noticeable on: assuming it's the mm changes I'd guess it's non-cached machines (possibly SX-machines) for which a TLB flush will result in a noticeable performance-loss. So if you notice a slowdown, please mail me that kind of info as well. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: VM86 Message-ID: <1992Aug29.091200.16019@klaava.Helsinki.FI> Date: 29 Aug 92 09:12:00 GMT References: <1992Aug29.065940.1256@athena.mit.edu> Organization: University of Helsinki Lines: 68 In article <1992Aug29.065940.1256@athena.mit.edu> hammond@kwhpc.caseng.com (Kevin W. Hammond) writes: >I see with patch 2 there is a vm86.h file and I recall seeing some mention >of Linux supporting a virtual 8086 mode. Is this true and, if so, how does >one use the virtual 8086 driver? Yes, 0.97.pl2 has support for a vm86 mode: note that this is /not/ the same as a DOS emulator, but it can be used for that. The interface looks like this: void vm86(struct vm86_struct * info); where vm86_struct is defined in linux/vm86.h, and currently looks like this: struct vm86_struct { struct vm86_regs regs; unsigned long flag; } The flag value is not currently used, and I assume some additional fields will be added eventually (a page dirty map for efficient screen updating etc), but the above is enough for a simple DOS emulator. The vm86() system call is pretty simple: it loads the registers with the values in the 'regs' structure, and starts executing in vm86 mode. It will return to protected mode when a signal happens: when this happens the vm86 state is saved in the info structure and the signal handler is executed in normal 32-bit mode. The signal handlers can then use the vm86_struct information to see what is going on, and correcting any errors etc. A simple DOS emulator would look like this (pseudo-code): global struct vm86_struct info; main() { set up the DOS memory image at 0 - 1MB set up SIGSEGV and SIGILL etc signal handlers set up the initial regs etc in 'info' while (1) vm86(&info); } SIGILL_handler() { read 'info' to see why we got a SIGILL - if we can emulate it, update 'info' and return, else exit } SIGSEGV_handler() { see SIGILL } SIGALRM_handler() { check the screen memory in the vm86 box, and update the real screen every now and then. Do any other regular house-keeping fn's. } Note that all this happens in user mode - the kernel doesn't really do anything special about vm86 mode. And as the emulator and vm86 code is in the same process, is should be possible to make it all relatively efficient. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Beginners problems Message-ID: <1992Aug29.195511.23402@klaava.Helsinki.FI> Date: 29 Aug 92 19:55:11 GMT References: <1564@lysator.liu.se> Organization: University of Helsinki Lines: 57 In article <1564@lysator.liu.se> lien@lysator.liu.se (Jan Lien) writes: >Problems encountered with Linux 0.97 - help appreciated. >I have succesfully booted Linux on my pc, root system on hard drive. >However there are some serious problems, here listed in order of >percieved severity. > >- mtools does not recognize my G: and H: ms-dos logical drives on my > extended partition. I get the error ENOENT for these disks, but > they are in the proper table, as I can use C-D-E-F disks. Fdisk > finds them as hda9 and hda10. > Is this an built in constraint in Linux? I got error messages when > I tried to use hda10 for a linux disk. This is probably a limit in the rootdisks - I think the /dev/hdaX entries only go as far as /dev/hda8. The fix is very simple: just create the needed special files with mknod: # mknod /dev/hda9 b 3 9 # mknod /dev/hda10 b 3 10 etc. By doing a "ls -l /dev/hd*" you see the device numbers, and the setup should be pretty obvious when reading them. >- emacs over a serial port (/dev/ttys1 or /dev/ttys2) writes in the > mode line. Is there an error in termcap (vt100 terminal), or is > the number of lines set incorrectly? If it is number of lines, > where (and how) do I change them? The problem is the default number of rows that linux uses: I have stupidly set the value to 25 instead of the normal 24 for a vt100 terminal. The fix should once more be very simple: do a # stty rows 24 columns 80 or # eval `resize` on the line before staring up. >- where do I find information on what all the options to a command > does? (I can find out that there are -abcdefgh... to a command, > but what do they do?) The man-pages for most GNU things are in the sources - for some binaries (like fsck) no man page is available, and you have to read the actual source files. >- while logged in on a serial port (/dev/ttys1 or /dev/ttys2) and > doing a cat or cp to /dev/tty, if I repeatedly press ctrl-C > I get logged out. This is usually a mark of a bad compile of the shell, but I haven't seen it (but I use my own port of most relatively simple things). Don't know of any simple fix. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Will SLIP/PPP support be available soon? Message-ID: <1992Aug30.222112.14969@klaava.Helsinki.FI> Date: 30 Aug 92 22:21:12 GMT References: <9208302107.AA27751@cue.bc.ca> Organization: University of Helsinki Lines: 14 In article <9208302107.AA27751@cue.bc.ca> tdzubin@cue.bc.ca (Thomas Dzubin) writes: > >Is the TCP/IP stuff slated to be included in the next 'standard' Kernel >release (Linus?). Yes, the tcp/ip subdirectory will be part of the next major release (ie 0.98), although I won't have it compiled into the standard bootimage. People who need it can recompile the kernel easily enough, and it's not essential for the rest of the system. Linus PS. And yes, 'ps', 'free' etc will be slightly broken once more, but not too badly this time. ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: HD interrupts and IDE Message-ID: <1992Aug30.221612.14848@klaava.Helsinki.FI> Date: 30 Aug 92 22:16:12 GMT References: <1992Aug30.161030.5898@ncsu.edu> Organization: University of Helsinki Lines: 26 In article <1992Aug30.161030.5898@ncsu.edu> big@garfield.catt.ncsu.edu (Alan Porter) writes: > > >I have been getting the infamous "Unexpected HD interrupt" messages >whenever I do anything that requires a lot of disk activity (like tar, >or worse yet, rebuilding the kernel). > >Even more annoying, I also get the "HD timeout", the 4 second wait, and >then the "HD-controller reset". > >First, my system: >386-40, IDE drive (KLOC KL3120, 115 MB), 4 MB RAM, 60 MB Minix FS, 5 MB swap. This is "normal" for kalok drives: they give these unexpected interrupts for some unfathomable reason. I actually have a OEM manual for kalok drives (thanks to whoever got it to me), but it doesn't mention this kind of behaviour, so I guess it's a "undocumented feature", ie bug. The problem can be at least partly fixed by defining HD_DELAY in hd.c to something other than 0 - try different values until it disappears (starting with 1000 or something like that). It should get rid of at least most of the errors, as the problem seems to be that the drive isn't ready to accept a new command even though it indicates it is in the status register. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Broken symlinks ?? (followup) Message-ID: <1992Aug31.125539.5089@klaava.Helsinki.FI> Date: 31 Aug 92 12:55:39 GMT References: <1992Aug31.054608.2405@athena.mit.edu> Organization: University of Helsinki Lines: 21 In article <1992Aug31.054608.2405@athena.mit.edu> hammond@kwhpc.caseng.com writes: > >0.97 seems to fail if the actual executable is owned by root and has a mode of >711 (or actually, any mode that does not include read permission). If the executable >is owned by a non-root user, things do work correctly. Is this some sort of security >measure in the kernel? Maybe I (or anyone else) should look at the kernel code to >find out! It's a bug in 0.97.pl2, but I've corrected it already, and pl3 (out next weekend) will take care of it. The problem is that the current symlink code wants read-permissions to the file the symlink points to, due to me not thinking all the changes through when I updated to the better namei() routines in patch2. The interim solution while waiting for patch3 is to make all executables or directories that are pointed to by symlinks world readable, and the problem should go away. In case somebody wants to correct in in their kernel, the place to look at is fs/open.c and fs/namei.c - you should move the permission check from open_namei() to sys_open(). Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: .97 kernel and root disk/probs with swapping Message-ID: <1992Aug31.194716.16232@klaava.Helsinki.FI> Date: 31 Aug 92 19:47:16 GMT References: <6026@pdxgate.UUCP> <1992Aug31.024052.12351@cc.umontreal.ca> Organization: University of Helsinki Lines: 76 In article <1992Aug31.024052.12351@cc.umontreal.ca> duperval@ERE.UMontreal.CA (Duperval Laurent) writes: >In article <6026@pdxgate.UUCP> moyerg@rigel.cs.pdx.edu (gary a moyer) writes: >>I am now in the process of getting the kernel to compile however I am getting >>some strange results. I am using a 2M swap file (NOT partition). I get >>some errors during swaps like: >>rw_swap: bad swapfile >> >>This occurs during compilation using gcc 2.2.2d with 4M RAM and 2M swap. >>Any ideas? Thanks. > >I have similar problems with kernel compilation. I have 4M of memory and 8M >swap space. When compiling I get an out of memory, out of swap space error. >I'm running all the stuff that was on mcc-interim 0.96c (gcc 2.2.2, kernel >0.96c). The "bad swapfile" problem is most usually due to (wait for it) a bad swapfile. Hmm. Maybe I should use cryptic numbers and give something like "ERR192SWP" instead - but that would also mean I'd have to write some documentation on the thing. Not good. Anyway, to make a swapfile, it's not enough to just run "mkswap" - mkswap just writes the swap signature and some bad-page info. You actually have to create the swapfile with the correct size and without holes first. How you create the swapfile is totally up to you, but the normal thing to do is: # dd if=/dev/zero of=swapfile bs=1024 count=XXXX where XXXX is the size of the file in kilobytes. You now have an empty file which is exactly XXXX blocks long. To mark it swappable, you then run mkswap on it and sync: # mkswap swapfile XXXX # sync You now have a swapfile that is ready to be used: swapping is then enabled with # swapon swapfile It's normal to put the 'swapon' command in your /etc/rc.local or whatever - but you can do it by hand at each reboot if you want to. Note that if you use a swap-paritition, you obviosuly don't have to create it first with "dd" or whetever: just make sure you have a good partition free, and run "mkswap" on it. With swap partitions, it's generally a good idea to map out bad spots (or you'll get all sorts of nasty errors), so use the "-c" switch for this: # mkswap -c /dev/hdXX XXXX # sync and # swapon /dev/hdXX Swapping from a partition is a lot faster than swapping from a file, but creating a file is easier, and it's easier to remove or resize. >I never encountered this prblem before and I thought I had plenty of room. >BTW, if anyone is interested, my make fails on chr_drv/tty_io.c when I have >one console open and on chr_drv/console.c when two consoles are open. > >Also, what are these 'put_tty_queue' declarations disagree about 'inline' >errors I get. What do they mean and could they be a hint as to what is going >wrong? the "disagree about inline" message is arguably a gcc bug: it's an uncommonly stupid warning, and I don't know why gcc prints it. It's probably easy to get rid of by just putting a "inline" before the prototype in include/linux/tty.h, but I'm too lazy to even test it out. The way gcc inline (nonstatic, nonexternal) functions work, it's totally illogical to ask it to be prototyped that way. I don't mind too much: as long as my only gripes with gcc are of this type, I'm happy. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: getting "bogus do_no_page"; strange vi behavior Message-ID: <1992Aug31.195805.16530@klaava.Helsinki.FI> Date: 31 Aug 92 19:58:05 GMT References: <1992Aug31.145123.20915@novell.com> Organization: University of Helsinki Lines: 24 In article <1992Aug31.145123.20915@novell.com> bboerner@novdpd.uucp (Brendan B. Boerner) writes: >Hello, using Linux 0.97 and later 0.92 Pl#2, when compiling (among >other things) on a (386/16 w/a tad under 5MB of RAM) I start getting >spurious "bogus do_no_page" messages. These don't appear on my >girlfriend's computer (486/33 w/8MB RAM). The "bogus do_no_page" error seems to happen on older 386 chips: they sometimes give spurious page-faults. The linux approach is just to print the warning message and return: it seems to work, and the 386 will happily do the page translation correctly the next time around. You should be able to safely uncomment the printk() that prints the message: especially if linux doesn't seem to mind, and you have no other problems. >Also, after upgrading to 0.97, I noticed that vi has been acting >funny. While inserting into a line, it starts adding spaces. Using ^L >will redraw the screen and show that the spaces really don't exist. I think this is due to an incorrect /etc/termcap: the correct fix is naturally just to dump 'vi' and start using some emacs-like editor :-) If that isn't possible, try getting a new termcap from a newer rootdisk, and the problem should hopefully disappear. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: GNU kids on the block? (sorry... couldn't resist) Message-ID: <1992Aug31.200513.16637@klaava.Helsinki.FI> Date: 31 Aug 92 20:05:13 GMT References: <1992Aug31.185733.21037@hpmcaa.mcm.hp.com> Organization: University of Helsinki Lines: 23 In article <1992Aug31.185733.21037@hpmcaa.mcm.hp.com> bryanf@hpmcaa (Bryan Ford) writes: >lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >> steve@hacker.UUCP (Stephen M. Youndt) writes: >> : but I feel very strongly about one thing [...] >> : (according to rumors :-), and that's reloadable device drivers. >> : It just seems that the micro kernel people are the only ones doing it. >> >> SunOS has had loadable device drivers, system calls, and functions (I'm >> not sure what you use the last one for but there it is) since SunOS 4.1. > >So has AmigaDOS, since 1.0. :-) I've got a month or two to implement them yet (evil grin) - I'm not even up to 0.98, and I'm seriously thinking about it. No promises, but it looks simple enough (after all: why do you think I gave the kernel a 1GB virtual address space when changing the mm...) Linus PS. Seriously: it will take a few releases to get anything working - 0.98 may have some support for it, but these things take time: 0.12 had the kernel support for shared libraries, but only now are they getting mature. ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Swap files (was: Re: .97 kernel and root disk/probs with swapping) Message-ID: <1992Sep1.083154.5064@klaava.Helsinki.FI> Date: 1 Sep 92 08:31:54 GMT References: <1992Aug31.024052.12351@cc.umontreal.ca> <1992Aug31.194716.16232@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 54 In article B.J.Lippolt@research.ptt.nl writes: > >On the subject of swapping. > >Would it be possible to implement a scheme (a la SunOS) where you can >'add' swap files to the swap space? E.g. I have a 8Mb swap partition, and >when I need more (which happens once in a while) I just create a swap >file and add it to my 8 Mb swap space. Would this be a minor (i.e. I >can do it myself) or a major change? It wouldn't be too hard: right now swap-map numbers are 31-bit entities, and it would be pretty easy to use the high 7 bits to be indexes to the swap-file, while keeping the low 24 bits as the page-in-swapfile index. The changes would be pretty minimal, although it would need a thorough understanding of the swapping setup. It's an interesting thought: I might implement it myself some time when I have nothing better to do. Anyway - if you are interested to implement it yourself, the thing to do is roughly: - change all the swap-file related variables to be arrays, and add a "nr_swapfiles" variable that keeps count of how many are in use. The variables are rougly: swap_bitmap, swap_lockmap, swap_device, swap_file as well as some optimization values (lowest_bit, highest_bit) used so that the routines wouldn't have to go through the full bitmap all the time. It would look a bit like this: struct swap_info { struct inode * swap_file; int swap_device; char * swap_bitmap; char * swap_lockmap; int lowest_bit, int highest_bit; } swap_info[MAX_SWAPFILES]; int nr_swapfiles = 0; - change the "get_swap_page()", "rw_swap_page()" and "swap_free()" functions to understand the high bits of the swap block-nr, and naturally the sys_swapon() system call to enable it all. The changes shouldn't actually be more than a couple of lines in each place, and it shouldn't be more than a couple of hours work - assuming you understand the code. On the other hand, I've been looking into a "sys_swapoff()" system call (which needs a bit more thought: you have to make sure the swapfile isn't used by anything), and I might implement the aboev at the same time. No promises. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: io.h/iopl Message-ID: <1992Sep1.152745.17949@klaava.Helsinki.FI> Date: 1 Sep 92 15:27:45 GMT References: <1992Sep1.123648.18859@cbnewsd.cb.att.com> Organization: University of Helsinki Lines: 50 In article <1992Sep1.123648.18859@cbnewsd.cb.att.com> asmith@cbnewsd.cb.att.com (arthur.c.smith) writes: >Hi, > I have been working on an S3 driver for X and have an 80X86 asm program >under dos that will setup the S3 chip correctly (and uses the enhanced >rectangle fill command to clear the screen 8-)). I am trying to port this >over to Linux. I am having two problems. 1) In trying to use sys_iopl() >I tried to write it as _syscall1(void,110,int,3) and include unistd.h >(and __LIBRARY__ defined). I get an error when this compiles. Is there >a better way to do this? That is not how you are supposed to use the _syscallX macros - they just build the system call for you. You are supposed to do it like this: static _syscall1(int,iopl,int,level) /* note: no semicolon */ main() { if (iopl(3)) { perror("iopl"); exit(1); } .... } Also note that gcc-2.2.2d should have the iopl() system call in the standard library, so the _syscall1() things isn't needed at all if you use the new gcc. Then a word of warning: using iopl() is /not/ recommended. If you do some stupid programming error, there is simply too big a chance to mess up: disabling interrupts will totally hose the machine (which is why iopl() only works for the super-user, but even the super-user should be careful about it). If you can get by by using the ioperm() system call (which only works for the 0-0x3ff range of IO ports), use that instead. ioperm() gives only access to a selected subset of the IO ports, and doesn't mean you can disable interrupts etc. > 2) Trying to port to C: When I include /usr/src/linux/ >include/asm/io.h and use outb I get undefined _outb referenced in .text. In >looking at io.h it appears as if the outb function is defined as extern but >is also defined in io.h??? Sounds weird: the inb() and outb() functions should work fine as long as you have included . You might want to make sure you have either "-finline-functions" or "-O" on the gcc command-line: I haven't checked what gcc thinks about inline-functions without those. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Swap files (was: Re: .97 kernel and root disk/probs with swapping) Message-ID: <1992Sep1.153412.18136@klaava.Helsinki.FI> Date: 1 Sep 92 15:34:12 GMT References: <1992Aug31.194716.16232@klaava.Helsinki.FI> <1992Sep1.083154.5064@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 22 In article <1992Sep1.083154.5064@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: >In article B.J.Lippolt@research.ptt.nl writes: >> >>On the subject of swapping. >> >>Would it be possible to implement a scheme (a la SunOS) where you can >>'add' swap files to the swap space? E.g. I have a 8Mb swap partition, and >>when I need more (which happens once in a while) I just create a swap >>file and add it to my 8 Mb swap space. Would this be a minor (i.e. I >>can do it myself) or a major change? > >It wouldn't be too hard: right now swap-map numbers are 31-bit entities, [ explanation on how to implement it deleted ] Ok, don't implement this: I already did it, and the (minor, as promised) changes will be in the next patch. I'm currently running linux with two different swapfiles, and it accepts up to 8 different files (and up to 128 after changing a single #define and recompiling). I haven't implemented "swapoff()" yet, but I guess that too will be implemented today. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: symlinks in 0.97pl2 Message-ID: <1992Sep3.103546.11747@klaava.Helsinki.FI> Date: 3 Sep 92 10:35:46 GMT References: <1992Aug31.020059.21670@athena.mit.edu> <1992Sep2.205903.6121@julian.uwo.ca> Organization: University of Helsinki Lines: 27 In article <1992Sep2.205903.6121@julian.uwo.ca> klode@syslab.csd.uwo.ca (Claude Morin) writes: >SunOS 4.1.1 allows the following: > > r-x--x--x ... ff* > lrwxrwxrwx ... bob -> ff* > > rubble[400] % cat bob > #!/bin/sh - > echo hello > rubble[401] % ./ff > hello > rubble[402] % ./bob > hello > >So I guess that linux is 'broken'. Perhaps linux is displaying correct POSIX >behaviour... No, linux isn't "posixly" correct: it's a bug that creapt in with the changed symlink code in 0.97.pl2. The pl2 behaviour is to require read-permissions of any target of a symlink, which is definitely wrong - but I already corrected it, and pl3 (out Saturday) gets it right. pl3 also contains the multiple swap-file and swapoff() code, as well as various other minor fixes. If pl3 is ok, I'll probably release it later as 0.98 with no essential changes: just adding the tcpip directory and possibly other "secondary" code. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Benchmarking under Linux (was Re: New 486 Suggestions? Message-ID: <1992Sep4.100706.12473@klaava.Helsinki.FI> Date: 4 Sep 92 10:07:06 GMT References: <1992Aug31.180211.24228@news.acns.nwu.edu> <1992Aug31.210041.21832@novell.com> <1992Sep2.175417.11302@pool.info.sunyit.edu> Organization: University of Helsinki Lines: 28 In article <1992Aug31.210041.21832@novell.com> bboerner@novell.com (Brendan B. Boerner) writes: > >This has me wondering: does anyone have any benchmarking or performance >metric programs for Linux? I've got a 386/16Mhz w/a tad under 5MB of >RAM and it takes me somewhere between 3-4hours to build the kernel. On >my girlfriend's machine, a 486/33 w/8MB RAM, it takes under 10 >minutes. I'd like to get an idea of where I could improve >performance. RAM space is the first thing to look for: gcc eats memory like mad, and swapping is slow especially with the older kernels. I hope my changes to the swap-algorithms in 0.97.pl3 will help people with slow machines: it does seem to help even on my 8MB machine (kernel compilation time when running X+some xterms fell from 18 minutes to 15). The main change was to use a page-used counter instead of just a swp bitmap, which allows fork() to be speeded up /a lot/ when swapping. But processor speed can be very important under linux: not just for the obvious user-level speedup, but due to better response to disk-drive interrupts and the like. Faster machines may simply read the disk at the full 1:1 interleave - with slower systems, it's possible that the HD driver doesn't keep up, and you get the dreaded 1-block/rotation syndrome, which really hurts when swapping. This problem is probably especially notable on 386SX machines: the 386 interrupt handling is inherently slow, but if the memory badwidth is further reduced by the 16-bit bus, interrupt response is probably ever worse. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.97 patchlevel 3 available Message-ID: <1992Sep5.184606.11361@klaava.Helsinki.FI> Date: 5 Sep 92 18:46:06 GMT Organization: University of Helsinki Lines: 110 [ This was already sent to the NORMAL mailing-list, and this is essentially the same announcement. ] Well, 0.97.pl3 is available both as full source (linux-0.97.3.tar.Z) and as a context diff (linux-0.97.patch3.Z) on nic.funet.fi, in the normal directory (pob/OS/Linux/testing/Linus). It seems some line is once more down on the way to the US, so I haven't uploaded it to tsx-11 yet. Also, I haven't been able to use the pub/Linux/Linus directory on sunsite (it dies on me when I try to send the group password), so I don't know when sunsite will get the new release. Patch3 is almost 100kB even compressed, as there were quite big changes in the mm and minix fs. No major new features: there are two new system calls: swapoff(const char * swapfile) and wait4(), and linux accepts several swap-files, but the rest of the thing is mostly bug-fixes or simply rewrites. Major changes: - new swap-page handling: linux no longer uses just one bit to keep track of used swap-space, but a counter for each swap-page. This allows processes to share swap-pages after a fork(), and should result in /major/ performance increases on machines with less memory. I've seen better performance even with 8MB - I wouldn't be surprised if 4MB machines would re-compile the kernel noticeably faster under pl3. I'd be interested to hear numbers. - The low 1MB memory that isn't used directly by the kernel is now swappable memory, instead of being hardcoded for buffer cache. The patches for this were originally by tytso, and I expanded on it a bit more. This might also help better performance on 2-4MB machines. Note that this does /not/ mean that you can use 1M machines for linux: linux still needs some extended memory. - the dosfs has been upgraded to dosfs.8 - patches by almesber. - I edited the minix fs pretty heavily to remove a couple of race- conditions. The same races still exist in the extended fs, as I didn't have time to edit that yet. The minix-fs took precedence as I know that better, and extfs isn't "official" yet anyway. other changes: - the mouse-driver now handles both Logitech (minor = 0) and PS/2 (minor = 1) busmice. - there is a proc-fs for access to user memory/files etc. - better support for the tcp/ip patches (but see below...) - corrected symlink and /dev/[k]mem behaviour - Lars Wirzenius' README (with minimal comments by me) and the GNU COPYING notice are now part of the normal kernel setup, and can be found in the tar-archive. - the floppy ioctl() to get the FD parameters no longer requires root priviledges. Thus, the msdos emulator runs even for a normal user. Some comments on patchlevel 3: mm: The swap-page handling resulted in a reduction of swap-file (or partition) size to a maximum of 16MB per file. It's nothing inherent to the code, but it eased some algorithms, so I didn't bother coding around it. After all, 16MB is enough for most people, and if you want more, you can have up to 128 swapfiles of 16MB each. If I get enough hate-mail about it, I might just try to find the energy to correct it. Maybe. Bigger swapfiles will still work, but linux will take advantage of only the low 16MB. Also, there is no nifty logic to try to optimize the usage of the swap-files: pages are simply allocated from one swap-file until it fills up, and then the next swap-file is used. The memory management changes break ps/free once more, but not very much. Also, I changed the load-average counting, so 'w' also needs slight editing. On the other hand, I made '/dev/kmem' mmap()able, and 'ps' and 'free' should be edited to take advantage of that: it should result in much faster operation, as well as possibly using less real memory. fs: The fs changes should remove at least two races - the races don't happen very often, but they were theoretically possible, and might be the reason for some fs corruption problems that have been reported. The changes are related to the use of bmap() - the bmap interface doesn't really lend itself to some things that it was used for. Re-writing internal fs-functions not to use bmap not only should have removed any races, but also actually resulted in cleaner code. The proc-fs code isn't too beautiful, and I'll probably leave it out from 0.98 unless I can make it loadable. We'll see. If anybody wants to use it, you can do something like # mount -t proc /dev/ram /proc Instead of /dev/ram you can use any block device - it's not used, and is only a dummy as the proc-fs doesn't actually use any external device. (but note that the device is still marked as mounted, so you cannot mount it for anything else). kernel/mm/lib: The TCP/IP patches are also essentially in 0.97.pl3 - not the full TCP/IP directory, only the patches to the main kernel. NOTE!! I don't like the 'grab_malloc_pages()' function, so I left that out, and added a GFP_ATOMIC priority to get_free_page() that should be used instead. I hope this will be used (Ross?), as it's a lot cleaner. Also, I hope the tcp/ip people will clean up malloc() so that it doesn't panic instead of returning NULL etc. Ugly, ugly. This is related to the get_free_page(GFP_ATOMIC) changes, and I'd like to have patches as soon as possible - tcp/ip won't be part of the standard kernel until that can be cleaned up. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97 patchlevel 3 available Message-ID: <1992Sep7.080727.22080@klaava.Helsinki.FI> Date: 7 Sep 92 08:07:27 GMT References: <1992Sep5.184606.11361@klaava.Helsinki.FI> <1992Sep6.174044.28957@mo.hobby.nl> Organization: University of Helsinki Lines: 26 In article <1992Sep6.174044.28957@mo.hobby.nl> hans@mo.hobby.nl (Hans Oey) writes: > >Sure, 16 Mb is enough. Jeez, why would people ever need >more then 640 Kb? Swap partitions give far better >performance. Should we use up to 128 partitions? >Please remove this limitation on Linux. Would a beer or >two help you to find the energy? Actually, beer-drinking doesn't seem to help programming very much :-) And as people have been very concerned about the 16MB limit - don't panic. It's not inherent to anything like the DOS 640kB limit, and is there just because it was a bit easier to code that way - correcting it later won't break anything. So while this version and the next may have this limitation, it will go away (cleanly) - I just have to code some more. In case anybody is wondering why there is a 16MB limit in the pl3 code, it's very simple: I use a character array to store the swap-page-counts, and that array just happens to be 4096 bytes long, as that's the biggest easily allocable unit of memory in the current kernel. So I just allocate 4096 bytes: 4096 swap-page-counters = 16MB swapspace. So the only thing that I have to do to allow bigger swapfiles is to allocate more memory - SMOP, but irritating and boring. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Can't get 0.97pl3 to boot Message-ID: <1992Sep7.081220.22423@klaava.Helsinki.FI> Date: 7 Sep 92 08:12:20 GMT References: <715841111snx@temple.demon.co.uk.demon.co.uk> Organization: University of Helsinki Lines: 23 In article <715841111snx@temple.demon.co.uk.demon.co.uk> pdc@temple.demon.co.uk.demon.co.uk (Piers Cawley) writes: > >But: I just pulled the new 0.97pl3 sources down from nic.funet.fi, hacked >keyboard.c so that # and @ are in the right place and compiled. Thus far, no >problems. However, when I copied /usr/src/linux/Image to /etc, did the rdev >incantation over it and rebooted, I got the following message: [ deleted ] I'd be much happier if people using shoelace would try booting from a floppy (or using lilo) - right now I always suspect a problem with shoelace when I see these kinds of messages. Shoelace isn't supposed to be used any more: please get lilo instead. Shoelace has several problems: - it doesn't handle holes in the Image file gracefully - nobody seems to remember if there are any limits to the size shoelace can load. - shoelace cannot handle anything else but the minix fs. So please try booting from a floppy, and resubmit the problem-report if it still won't work. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: HD-timeout problems Message-ID: <1992Sep6.091302.29969@klaava.Helsinki.FI> Date: 6 Sep 92 09:13:02 GMT References: <1992Sep5.201920.3244@afterlife.ncsc.mil> Organization: University of Helsinki Lines: 41 In article <1992Sep5.201920.3244@afterlife.ncsc.mil> swaliff@afterlife.ncsc.mil (Steve Aliff) writes: >I'm experiencing enough "HD-Timeout/HD-controller reset" messages to >have become frustrated (irritated?) with it. This occurs both with >the MCC release (.97p2) and the SLS release (.96c I believe). The >SLS kernel has the "static int reset = 0" code in it. (I built a new >kernel just for kicks. And The problem occurred BEFORE and after I >built the kernel. ;-) ) The problem doesn't appear to happen when I >crank the clock back from 33MHz to 10Mhz. Needless to say, that's >not an acceptable solution. There are two things you can do to alleviate the problem. In order of "preferability": - check that your IO bus runs at 8MHz or lower. Having a 11MHz bus seems to be pretty standard setup, but it's unsafe, and running beyond specs. Check out your extended setup (press DEL on bootup for AMI bios or whatever) - it's usually something like Bus speed: CLK/2, CLK/3, CLK/4, CLK/5. for a 33MHz machine, CLK/4 should give an acceptable 8.25MHz clock for the IO bus. Your setup may also allow you to set ISA bus waitstates, and editing this field may help. Read the motherboard manual if you have one. - edit the HD_DELAY value in kernel/blk_drv/hd.c. It is normally 0, but setting it to some other value may help some buggy controllers/drives. Test out different values, starting off with 1000, and try to find the lowest value you can get that works. And finally, you can also try changing the HD controller card: a cheap multi-io card may have some weird problem that doesn't show up under DOS. If you can swap cards with someone just for testing purposes, and that fixes the problem, getting a new controller card may be the solution. But as this may be impossible (or just too expensive, even though IDE controllers should be cheap), try out the above first. All the above fixes have helped - it may not in your case, but it's worth checking out. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux 0.97p2 compatibility, GCC/SHAREDLIBS/JUMPTABLES. Message-ID: <1992Sep6.185549.8454@klaava.Helsinki.FI> Date: 6 Sep 92 18:55:49 GMT References: Organization: University of Helsinki Lines: 71 In article balasub@organ.cis.ohio-state.edu (Krishna Balasubramanian) writes: > >GCC main releases, the corresponding linux version and some >distributions that use this version of GCC are approximately >as follows: (see the GCC FAQ to find out more). > >1) 2.11c, May 19 linux 0.96 x11v1.0 >2) 2.2.2, Jun 27 > linux 0.96ap4 rootdisk-0.97, x11v1.1, SLS, MCC-0.96c. >3) 2.2.2d Aug 12 > linux 0.97p1 rootdisk-0.97.1 , MCC-0.97p2 > >There will probably be a new GCC version with X11 in a week or so. Right. And in case anybody is nervous about the inverse relation (ie running old programs under new kernel releases), that should always work *barring bugs or "undocumented features"*. So all old binaries will generally work on new versions of the kernel. The ptrace() interface was changed in 0.95 - but that was before gdb was publically available, and it broke no binaries. Other than things like that, all "nice" programs should work from one release to another. They may not be able to use new features (VFS etc), but they should work as well as they ever did. Note that new gcc versions, new features etc have made a recompile a good idea, but not strictly necessary - I still use the following programs: -rwxr-xr-x 1 torvalds uucp 9491 Aug 19 1991 /bin/sync -rwxr-xr-x 1 torvalds uucp 20640 Aug 21 1991 /usr/bin/dhrystone -rwxr-xr-x 1 torvalds uucp 72091 Sep 8 1991 /usr/bin/egrep -rwxr-xr-x 1 torvalds uucp 72090 Sep 8 1991 /usr/bin/grep -rwxr-xr-x 1 torvalds uucp 31176 Sep 13 1991 /usr/bin/od and they work perfectly ok even though some of them are probably from before the 0.01 release. "non-nice" programs include the 'ps'-suite of programs that muck around with kernel memory, and simply buggy programs that may work on older releases. An example of the latter is anything that accesses memory that it hasn't first allocated with 'brk()'. Those programs worked fine in 0.96, but 0.96b (I think) adopted the standard unix practice of sending such a program a SIGSEGV. Similarly, some 'mount' binaries won't work under 0.97.pl2 even though they worked on pl1. They did a no-no that just happened to go unchecked in the older kernel. Another example of a program that didn't work with pl2 was "lilo" - it depended on the stat() system call returning the same buffer-size as used internally in the kernel, which no longer is necessarily true (and just happened to work in earlier versions). Of course, there are also kernel bugs that can result in a binary not working under a new release: this happened in pl2 with the symlink code and to a lesser extent with /dev/mem. I generally try to fix that kind of thing as fast as possible: pl3 has these corrected. So if you are using an old kernel in the fear that things won't work with a newer version, you should probably at least try to upgrade: the chances are everything works fine even if you don't have the latest user-level binaries. On the other hand, it may be only prudent to wait a while until a release has shown itself to be stable - people who are happy with their current kernel don't necessarily need to upgrade (but don't be surprised if some new binary doesn't work). Linus PS. None of the above means that future versions of linux will necessarily be 100% compatible. If I decide it's worth it, I might break all old programs by doing something in a more clever way. But I'll document it very clearly if I'm aware of the problem. And it's not very likely: after all I'm running the same programs as everybody else (and older versions than some), and I don't feel any terrible urges to recompile everything. =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Progress report? Message-ID: <1992Sep7.142246.22137@klaava.Helsinki.FI> Date: 7 Sep 92 14:22:46 GMT References: <1992Sep7.125312.20025@wam.umd.edu> Organization: University of Helsinki Lines: 79 In article <1992Sep7.125312.20025@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes: >I've been away for the Summer, and have missed most of c.o.l. Could >someone who's been following it for the the Summer please let me know >what I've missed. My last kernel is 0.96. Get 0.97.pl4 - it seems to be stable (knock wood: I haven't gotten any reports on it yet), and fixes a lot of things. Out today, and available at "nic.funet.fi" "pub/OS/Linux/testing/Linus". You might want to reinstall from scratch: the mcc or SLS releases look promising, although I naturally haven't tried either. They get you the current compiler and good versions of most of the standard tools (although you should probably get the new 'mount' package that fixes a lot of bugs. Good work - I liked it) >Specifically, is there a DOS emulator yet? Have the VM86 patches at >least made it into the standard distribution? Have my code-page >patches made it into the standard distribution? The original VM86 patches never made it into the standard kernel, but I implemented a very similar vm86() system call when rewriting the mm (it got very easy after that), and yes, there is a working msdos emulator available. But it's very simple (but fun: having DOS running under X11 in an xterm sure gives a professional feeling to the system :-), and gives up for any program that tries to do anything more complicated, so it's not useable for "real" work yet. You can boot up a msdos floppy on it, and play around with "dir" etc, but that's about it (has anybody tried early versions of turbo-pascal? they should work on almost anything). Expect to hack on it before it's actually practical. As to any code-page patches, I have to admit I can't remember them, so I don't know if the current kernel does something similar. >My GCC library is marked lib92.04.06. Is there a new one? If I get >the new one, do I have to recompile all of my programs? Do we have >jump-tables yet so that when a newer library comes out programs won't >have to be recompiled? Wait a week or so for the next release, which hopefully will use the "final" jump-table setup (as well as having new X11 libraries etc). After that, the libraries should finally be stable (sure...) - the libraries already seem to work well, but they were changed to take advantage of the new mm setup, and the new version is in testing right now. lib92.04.06 is totally obsolete, and I doubt it can be found anywhere any more (I think I removed it from my disk a month ago, and most people probably never even saw it). >Is there anything else I would want to know about? Not really: 0.97.pl4 has some new features (/many/ new features when compared to 0.96) and should be faster/better etc, but the best way to find out is probably just to get the new system. Anything older than 0.96c.pl2 should probably not be used any more: 0.96c.pl2 is pretty stable, but I do believe 0.97.pl4 is better in almost all respects (it's bigger, but uses memory better, so you should actually have more free mem anyway). It's not too much tested, so I'm still keeping my fingers crossed, but even if there are bugs it's sure to be better than unpatched 0.96 which could be crashed just by catting some binaries to the VC's. Tcp/ip is getting there, and I expect it to be in the standard kernel in a couple of weeks. The extended filesystem is still in a bit of a flux, but most other things should hopefully have calmed down now (I can't guarantee all the minix-fs bugs are gone, but I feel pretty good about it all). I'm finally getting happy about the kernel: I have no major project going on any more. Naturally there are "details" like loadable device drivers, shmem(), mmap() etc that are interesting, and need to be implemented one way or another, but I've been feeling content since 0.97.2, and while I had to fix a couple of bugs in it, I still think 1.0 can be reality without any more major rewrites. Linus (Note: "feeling good about it" does NOT mean I'll stop working on it after 1.0 - I distinctly remember feeling good about version 0.12, and things have certainly changed since then. I just enjoy feeling good about my code, so I try to do it as much as possible :-) ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Progress report? Message-ID: <1992Sep7.173250.14016@klaava.Helsinki.FI> Date: 7 Sep 92 17:32:50 GMT References: <1992Sep7.125312.20025@wam.umd.edu> <1992Sep7.142246.22137@klaava.Helsinki.FI> <1992Sep7.163715.8229@fwi.uva.nl> Organization: University of Helsinki Lines: 29 In article <1992Sep7.163715.8229@fwi.uva.nl> vesseur@fwi.uva.nl (Joep Vesseur) writes: >torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: > >>Get 0.97.pl4 - it seems to be stable (knock wood: I haven't gotten any >>reports on it yet), > >c'mone linus, give us a break: it's out for only 2hrs 40mins :-) "ONLY" 2hrs 40mins? WHAT? How much time do you want to thoroughly test out a new version? Lazy bums (*) Actually, the pl4 changes are small enough that I hope there are no new bugs hiding in there, so pl4 should be as stable as pl3 - with the added advantage of not having the truncate bug. And I haven't gotten any bad reactions to pl3 yet. On the other hand, I guess most people haven't had time to upgrade even that far... Even the pl3 patches, while big, were pretty simple: mostly cleanups and some relatively straightforward swapping changes. While bugs are always possible, the pl3/4 changes aren't of the type that keeps me awake nights wondering if they will work, and are likely to work without major problems (famous last words...) Linus (*) No, I'm not serious. Lack of smilies doesn't /always/ mean I'm dead serious. Although some problems (especially HD-driver-related) have in fact been corrected with the help of beta-testers that were ready to test out several new versions/day. Unsung heroes, and all that... ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: GP faults and other trivia. . . Message-ID: <1992Sep9.094232.17759@klaava.Helsinki.FI> Date: 9 Sep 92 09:42:32 GMT References: <1992Sep8.104048.1@ualr.edu> Organization: University of Helsinki Lines: 87 In article <1992Sep8.104048.1@ualr.edu> nmspillers@ualr.edu writes: > >Anyhoo, the crux of my question is this--I'm working with Linux 0.96c >(no patches yet, I want to solve this problem first) and trying to compile >the kernel. I usually get a general protection fault somewhere in the kernel >compile, this leads to a 4-11 meg (no lie!) core and the compile degenerates >into signal 11 and 6 compiler errors. [ deleted ] There has been some talk about these kinds of things lately, so I might as well answer this.. If you see intermittent system failure (core dumping in gcc etc) that are not easily repeatable, and don't necessarily happen at the same location every time, there are a couple of possible reasons: (a) kernel bugs (b) weird/buggy hardware (c) installation problems (a) is certainly possible, although the fact that the same thing works on a lot of other machines/setups does make me wonder about some reports. (c) on the other hand usually results in easily repeatable problems: they occur at the same point each time. The above (mostly deleted) description does sound like a memory problem: I should probably enable the NMI just to get a warning about it, but I think current versions of linux disable it at bootup (I think I disable it as soon as possible as the system cannot handle it during setup, and after the system is up and running and a NMI could be handled, I never re-enable them. I haven't looked into in a long time, so I could be wrong.) Alternate reasons are disk read errors, although the drivers do check error conditions, and you should see kernel messages if they occur. And if you are wondering "why only gcc?", the reason is probably that gcc is the one program that usually eats up most of your memory, and actively shuffles things around. So if you have a bad memory chip or the linux disk driver has some problems, they usually show up in gcc - that's when all the buffers are in use, and most of your memory is being excercised a lot. Note that memory problems are more likely to show up under linux-0.97 and newer: not because they are more fragile, but simply because they use memory much more dynamically, and are more likely to take full advantage of the memory you have got. So the first things to check when seeing problems like the above is if it's hardware-related: one good way to do this is usually to slow down the machine to 8MHz or whetever, and see if the errors go away. If they do, it's probably not a software bug (although races etc can be timing-dependent: not very frequent). Other things you can do is try out some system testing software: but note that linux usually is a better system tester than most of these especially if they run onder 16-bit DOS and don't check 32-bit accesses to high memory etc. ----- change of subject Reading the above, your reaction might be "he's obviously trying to blame the hardware to get out of a tight spot". True. But it's also a case of standard bug-reporting of a operating system: with most other programs you can usually safely blame the program. While any bug report is preferable to none, there are things you can do to help me find it all. So I might as well use this post to mention some of them, true of most bug-reports: - mention all the necessary information. Too much data can be confusing (and boring), and too little can lead to other problems, so this isn't easy. Use your own judgement, but THINK about it a bit before. - try to make it repeatable, and find the minimal example. This is also almost always difficult or impossible, as the obvious bugs are certainly fixed, but it helps /a lot/ if you can simplify the bug-report a bit. - if you cannot make it repeatable or simple, assume it's a hardware problem, and start from that. Try different setups. If possible, different machines, but if not, try to change your setup as much as possible, and see if anything changes. - If the problem changes or disappears due to hardware changes, it might still be a software bug, so you might still want to send it in as such. But add your test-results to the report. And if the problem seems to be hardware-independent, mentioning the fact that you tested it it in your report is likely to get your report a higher priority. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: problems making a swap partition useable Keywords: 0.97.1 Message-ID: <1992Sep9.095543.19608@klaava.Helsinki.FI> Date: 9 Sep 92 09:55:43 GMT References: <1992Sep8.162500.16716@tamsun.tamu.edu> Organization: University of Helsinki Lines: 34 In article <1992Sep8.162500.16716@tamsun.tamu.edu> greg@carnivore.tamu.edu (Greg Economides) writes: > >When I do: mkswap -c /dev/hda5 10583, I get this: > > mkswap: will not try to make swapdevice on /dev/hda5 > >I am wondering if mkswap is complaining because the partition does not >end at an even boundary (or whatever it is that the '+' indicates, I don't >remember the exact wording in the fdisk intro file). Hmm. This sounds like the message I put into the original mkfs sources that checked that mkfs didn't write over the full disk devices (/dev/hda and /dev/hdb). And as mkswap evolved from that, I assume the test also did. The reason you see it on /dev/hda5 is that I wrote mkfs (and the original mkswap) back in prehistoric times when linux still used the minix disk-numbering scheme: under minix, /dev/hdb0 (linux's /dev/hdb) has the same major/minor as linux's /dev/hda5. I guess the test has never gotten updated, as you see the problems so seldom (most people don't have or don't use a /dev/hda5). Actually there is a (ugly) workaround for this, assuming you have an error-free disk. Just do # mkswap tmp 10583 # cp tmp /dev/hda5 This won't try to find bad blocks, though, so it's not always a solution. The real solution is to find the mkswap/mkfs sources, look the the error message, and either remove the check, or update it to use the new minor numbers (3,0 and 3,64 instead of 3,0 and 3,5). Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: Unable to use floppies under Linux Message-ID: <1992Sep10.193917.5396@klaava.Helsinki.FI> Date: 10 Sep 92 19:39:17 GMT References: <1992Sep10.182648.12564@eua.ericsson.se> Organization: University of Helsinki Lines: 35 In article <1992Sep10.182648.12564@eua.ericsson.se> tmpcms@eua.ericsson.se (Carl-Michael Skoog) writes: >I've installed Linux about 20-30 times, and every single time the filesystem >ends up corrupted when I use some floppy-related command like tar(with /dev/fd0 >as file, pax and GNU tar alike), dd, fdformat... [ *BAD* problems deleted ] This certainly looks like the linux floppy driver has /major/ problems with your machine - just as a guess I'd assume it's some weird DMA incompatibility as the floppy driver is the only thing in the standard kernel which uses DMA. It would seem that the DMA accesses go all over your memory, resulting in weird and incorrect behaviour - writing over the wrong buffers, kernel data structures etc. >Could it be my hardware that is stabbing my back? 386BSD and MINIX works >fine though. >I will be infinitely grateful if someone can help me with this. As minix and 386bsd works, it would certainly seem to be a bug in the floppy driver. A very weird one, though - this is the first such report I've ever seen. If you are at all familiar with the PC's DMA setup, I'd suggest you take a look into floppy.c: setup_DMA(), which is the obvious first suspect. If anybody can come up with suggestions on what could be wrong, I'd certainly be interested - but as I cannot see the problem, I'm somewhat at a disadvantage to find it. On possibility is simply that it's a timing problem: even re-writing the floppy driver to use the slower outb_p commands instead of the current immoutb_p() might help. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: 0.97 patchlevel 5 available Message-ID: <1992Sep12.182131.2168@klaava.Helsinki.FI> Date: 12 Sep 92 18:21:31 GMT Organization: University of Helsinki Lines: 35 The subject says it all: the newest patches have been uploaded to nic.funet.fi: pub/OS/Linux/testing/Linus. Patchlevel 5 is available both as complete source (linux-0.97.5.tar.Z) or as a biggish patch against patchlevel 4 (linux-0.97.patch5.Z). Patch 5 fixes the extended filesystem problems (thanks to Remy Card), as well as including many smaller fixes (some more fs cleanups, the CDROM patches and several other minor changes). Pl5 finally removes even the last few header-files that were incompatible with the normal headers, so the "-nostdinc -I$(KERNELHDRS)" stuff is gone. Patch 5 should also fix the problems with iopl() that resulted in the X8514-server having problems with 0.97.pl2 and above. In case people are wondering, my schedule for 1.0 looks something like this: - 0.98 out in about a week: this is essentially 0.97.5 + the tcp/ip directory, as well as any fixes that may come up. I'll try to get the loadable driver interface into it too. - 0.99 out after 0.98 has been shaken down: a month or so. - 1.0 will be the same as 0.99: the only changes will be eventual trivial bug-fixes in case 0.99 has some problems. This is just to try to get over the "X.0" bug syndrome. There are a few on-going projects: depending on circumstances these will be implemented sooner or later, so I won't give any promises. These include: loadable drivers/fs's (alpha-patches already availabla), full support for different block-sizes (some work still required), and a extensive rewrite of the mm routines (I'll want to make a vmm interface similar to the vfs interface for the filesystem routines). Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97 patchlevel 5 available Message-ID: <1992Sep12.224241.5864@klaava.Helsinki.FI> Date: 12 Sep 92 22:42:41 GMT References: <1992Sep12.182131.2168@klaava.Helsinki.FI> <15255@borg.cs.unc.edu> Organization: University of Helsinki Lines: 42 In article <15255@borg.cs.unc.edu> martin@franck.cs.unc.edu (Kevin Martin) writes: >In article <1992Sep12.182131.2168@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: > >>Patch 5 should also fix the problems with iopl() that resulted in the >>X8514-server having problems with 0.97.pl2 and above. > >I've just tested the 8514/A X server with 0.97.pl5 and it works >beautifully. The problems with the X server appearing to hang when >quitting from TWM with the 0.97.pl2 and more recent kernels are >fixed. Thanks Linux! Actually, thank Kevin Martin: he was able to give me a good bug-report that made it pretty easy to track it all down (he even had a minimal program which showed the incorrect behaviour). Other changes that pl5 has include: - slightly edited : easily editable IO delay instructions. The default delay-instruction is now a 'inb' from port 0x80: this should be a bit safer than the outb. But you can easily change it to the "standard" two short jumps or whatever. - malloc() is cleaned up, and 'malloc_grab_pages()' is gone (Biro) - I cleaned up the internal inode structure a bit: i_data[] is no longer part of the base inode, but is instead part of the union of fs-dependent info. Pipes also have their own cleaner interface. - the msmouse patches are in: currently there is no valid test that a msmouse actually exists, so linux always says "mouse detected and installed", but that is nothing to worry about. - the msdos-fs one-line performance patch is in. The most important fix for ext-fs users should be the fact that pl5 should fix the ext-fs bugs: the ext-fs patches are essentially the same that pl3+4 did to the minix-fs. So now the new 'strip' should be safe on all filesystem types. Note that the upcoming release of gcc (and thus the upcoming X11 2.0) will require at least 0.97.pl4 in order to be safely used: I'll probably make a bootimage of 0.97.5 available for those that don't want to (or are unable to) recompile the kernel. I'll just wait a day or two to see if there are some unexpected problems with pl5. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97 patchlevel 5 available Message-ID: <1992Sep13.085901.16695@klaava.Helsinki.FI> Date: 13 Sep 92 08:59:01 GMT References: <1992Sep12.182131.2168@klaava.Helsinki.FI> <1992Sep12.214957.620@cambria.columbus.oh.us> Organization: University of Helsinki Lines: 52 In article <1992Sep12.214957.620@cambria.columbus.oh.us> bjones@cambria.columbus.oh.us (Bill Jones) writes: > >Well I rushed out and got 0.97.5, compiled it and installed it. All of a >sudden I began to get HD timeout errors (something I haven't seen since >0.12). Switched back to 0.97.4 and they all went away!? Argghh. It's probably the outb_p() changes - that is the only thing in the HD driver that changed. Look into linux/kernel/blk_drv/hd.c - if you get pl5 by getting the full source, it doesn't define REALLY_SLOW_IO any more, as I hoped it would be unnecessary. It looks like #undef REALLY_SLOW_IO #include #include #include and you should probably change the "undef" to "define". I'll change it back for the next version - it seems the REALLY_SLOW_IO define is still needed on some machines. If the above doesn't help (it should), you might also take a look at the actual delay instruction used to slow down IO. This can be found in linux/include/asm/io.h, and looks something like this: #ifdef SLOW_IO_BY_JUMPING #define __SLOW_DOWN_IO __asm__ __volatile__("jmp 1f\n1:\tjmp 1f\n1:") #else #define __SLOW_DOWN_IO __asm__ __volatile__("inb $0x80,%%al":::"ax") #endif #ifdef REALLY_SLOW_IO #define SLOW_DOWN_IO { __SLOW_DOWN_IO; __SLOW_DOWN_IO; __SLOW_DOWN_IO; __SLOW_DOWN_IO; } #else #define SLOW_DOWN_IO __SLOW_DOWN_IO #endif You might change the default slow-down instruction from __asm__ __volatile__("inb $0x80,%%al":::"ax") to __asm__ __volatile__("outb %al,$0x80") Whatever you do, I'd be very interested to hear what you did, and if it worked, so that I can get it fixed for the next version. Also, there seems to be some problem with the extended fs patches: either Remy's patches or the changes I made to the inode setup. So pl5 still seems to have some irritating bugs. I'll try to find it. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97 patchlevel 5 available Message-ID: <1992Sep13.103027.17973@klaava.Helsinki.FI> Date: 13 Sep 92 10:30:27 GMT References: <1992Sep12.182131.2168@klaava.Helsinki.FI> <1992Sep12.214957.620@cambria.columbus.oh.us> <1992Sep13.085901.16695@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 14 In article <1992Sep13.085901.16695@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: > >Also, there seems to be some problem with the extended fs patches: >either Remy's patches or the changes I made to the inode setup. So pl5 >still seems to have some irritating bugs. I'll try to find it. Well, I also found out that at least named pipes got broken by my inode reorganizations. Hope nobody is using them - the fix is simple (it's actually just a lack of proper wait-queue initializations), but I won't make a patch available until I've found most of these kinds of silly problems. But if you know you are using named pipes, don't upgrade to pl5 yet. Linus ================== ================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.linux Subject: Re: gcc 2.2.2 math lib bug??? Keywords: weirdness Message-ID: <1992Sep13.175040.24459@klaava.Helsinki.FI> Date: 13 Sep 92 17:50:40 GMT References: <1992Sep13.161713.8191@monu6.cc.monash.edu.au> Organization: University of Helsinki Lines: 17 In article <1992Sep13.161713.8191@monu6.cc.monash.edu.au> int177c@aurora.cc.monash.edu.au (Jae Won) writes: > > I found a weidness in gcc2.2.2d. It may be my silly code but I tested >the code with gcc compiler at uni(gcc...not sure of the version) and it worked >fine...well, like what I expected. The code is a edited fragment of a code >I am writing to do a monte carlo stuff. I use exp() function. It's more likely to be a problem with the 387-emulator: the emulator does *not* handle under/over-flows gracefully in its current form. The fix is either to get a real 387, check for underflows by hand, or fix the emulator. Fixing the emulator is obviously the optimal solution, but it takes some doing, and nobody seems interested (most people, including me, seem to have a 387). The fact that the emulator works "well enough" for most things makes it a pretty boring project, so nobody has done anything about it. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: patchlevel 6 Message-ID: <1992Sep20.171956.26108@klaava.Helsinki.FI> Date: 20 Sep 92 17:19:56 GMT Organization: University of Helsinki Lines: 27 You all know what the subject line means by now: in case you want to track my kernel versions, the weekly patch is available at nic.funet.fi, pub/OS/Linux/testing/Linus. This patch does not contain any major bug-fixes: it corrects named pipes that broke with pl5, and has some minor changes in the IO-instructions and the hd-driver, but those shouldn't matter for most of you. It does contain all the scsi-patches that I've gotten so far, so if the bootup sequence died on you in the scsi code, pl6 should correct this. The major part of the patch is tytso's serial line changes, making the tty structures dynamic. No more NR_PTY's - the number of pty's is now bounded only by the minor number setup (max 64 pty's) or the amount of memory available (opening a pty requires a page of memory for tty queues). Similarly for serial lines. The above just means that while pl6 can be useful, the changes to pl5 aren't big enough to worry about. Most people don't use named pipes, it seems, and the other changes are either cosmetic or hardware-dependent. I still hope people upgrade, if only so that I can get new bug-reports. I had hoped to release 0.98 this weekend, but studies and the scsi/hd problems put an end to that. 0.98 should be out next weekend or so. Expect the tcp/ip subdirectory and possibly some mm changes. Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: patchlevel 6 Message-ID: <1992Sep20.214558.1338@klaava.Helsinki.FI> Date: 20 Sep 92 21:45:58 GMT References: <1992Sep20.171956.26108@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 12 In article <1992Sep20.171956.26108@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes: >You all know what the subject line means by now: in case you want to >track my kernel versions, the weekly patch is available at nic.funet.fi, >pub/OS/Linux/testing/Linus. Arggh. While the full source was ok, the patch was generated with "+ignore-all-spaces" in the hope that it would be smaller that way. And yes, the patch is smaller, but it doesn't actually work :-( The full source to pl6 is ok, but if you got only the patch, you'll get errors when applying it. I'll put a corrected patch at nic at once. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.unix.sysv386,comp.windows.x,comp.os.linux,comp.unix.bsd,comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware Subject: Re: Free software and the future of support for Diamond products Keywords: Diamond, free-software Message-ID: <1992Sep21.164816.9162@klaava.Helsinki.FI> Date: 21 Sep 92 16:48:16 GMT References: <1992Sep20.000851.2641@cbnewsj.cb.att.com> <1992Sep21.150821.9472@crd.ge.com> <1992Sep21.154451.10085@cbnewsj.cb.att.com> Organization: University of Helsinki Lines: 33 In article <1992Sep21.154451.10085@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes: >In article <1992Sep21.150821.9472@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes: >> >> Youu've missed something. The kernel supports vm86 operation, and it >> is possible to drop into real mode, allow access to the i/o ports >> needed, and run the BIOS in real mode, then exit back to protected mode. >> I am not suggesting this, I'm just saying it can be done. > >Well. Learn something new every day. Does anyone have a code sample that >shows how this may be done? Hmm. The linux alpha DOS-emulator might be able to do it with some minor tweaking: you'd have to get the initial 'int 0x10' address from somewhere (as it's normally over-written by the kernel), and the process should do a mmap("/dev/mem") the put the bios/screen memory into the normal address space. Additionally, you can use the iopl() system call to give the process IO priviledges before switching to vm86 mode - that way you don't even have to emulate any IO instructions. Some additional setup to initialize the normal BIOS data areas, and off you go. The only thing that doesn't work with the current linux setup is to get the original offset to the 'int 0x10' call: a minor kernel diff to look it up at bootup would be possible. I don't know how other systems would do it, but it should certainly be possible - but I do not think it's a good idea. It's ugly, and it's not guaranteed to be safe: the BIOS call might do something nasty while it has IO priviledges if it assumes a normal DOS setup and the vm86 setup is incomplete. Besides, that way you can only set modes that the BIOS knows about - the X386 (XFree86) driver has already proven that programming the chipset directly can lead to much better results (ie nonstandard resolutions etc). Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97p6: no PGUP; NUM_LOCK? Message-ID: <1992Sep23.072224.24351@klaava.Helsinki.FI> Date: 23 Sep 92 07:22:24 GMT References: <1992Sep23.014210.19842@unislc.uucp> Organization: University of Helsinki Lines: 28 In article <1992Sep23.014210.19842@unislc.uucp> erc@unislc.uucp (Ed Carp) writes: >Two questions: > >1. Somewhere between p5 and p6, I lost Page Up and Page Down key > functionality for vi. Any bright ideas? In order to be more vt100 compatible, those keys (and the function keys) now send slightly different codes. I haven't seen any problem: at least uemacs worked fine both before and after. It's just an ongoing project of mine to foil all vi-users :-) >2. Isn't there a patch to turn NUM LOCK off when linux fires up? It's already in the standard kernel (as of pl6) - I think the thing to do is to add -DKBD_DEFLOCK=0 to the KEYBOARD define in the main Makefile (the same line that contains the "-DKBD_FINNISH" or whatever). You can also define any other standard lock defaults by changing the above to -DKBD_DEFLOCK=NUMLOCK+CAPSLOCK or similar. I haven't tested it - the define might be wrong, but check the keyboard.c file to see how it works. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.97 p6's README etc. Message-ID: <1992Sep23.124326.10022@klaava.Helsinki.FI> Date: 23 Sep 92 12:43:26 GMT References: <1992Sep23.051532.22588@wixer.cactus.org> Organization: University of Helsinki Lines: 34 In article <1992Sep23.051532.22588@wixer.cactus.org> rhodesia@wixer.cactus.org (Felix S. Gallo) writes: > > The README under 0.97 p6 now seems to have a few minor >faults. NR_PTYS, which it suggests is in include/linux/tty.h, >is no more. It seems to have been replaced by NR_CONSOLES, but >I'm hazy on this point right now. NR_PTY's does indeed not exist any longer - pty's are now dynamic, and you can have as many as the naming scheme (you fight it out) and the minor numbering (max 64) allows (assuming you have enough memory). NR_CONSOLES is a distinct entity: this defines how many virtual consoles you have (normally 8, although I think the standard init setup starts a login process only on the first 4). It's still hardcoded, and I don't think there is any pressing need to make the VC's dynamic. > But the really heinous thing, the absolutely worst >thing that could happen -- and the reason I'm dumping linux >immediately and buying windows 3.1 -- is that, at the very end >of the README, ever since 0.96c (as far as I can tell), the >signature is "Lars Wirzeniu". Please fix this glaring kernel >error *IMMEDIATELY!* This isn't a bug - it's just that I'm too lazy to write anything like the README, so Lasu wrote it, and I just put my own comments in there. But I can understand that windows 3.1 would seem like a much better alternative after reading the README. The "bug" is almost as heinous as the wrong patchlevel numbers that plagued the 0.96XX releases... (and if the "bug" is the missing "s" from "Wirzeniu" (yes, I like "quotes" (and parentheses)), then that is probably just due to 8-char user-name truncation that has taken over from unix) Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Finally: 0.98 Message-ID: <1992Sep29.211121.15619@klaava.Helsinki.FI> Date: 29 Sep 92 21:11:21 GMT Organization: University of Helsinki Lines: 35 Sorry for being late - I can't even show any great new features in 0.98, but at least it's out now, and available at the normal place (ie at nic.funet.fi, pub/OS/Linux/testing/Linus). So far there is only a full-source version available, although I'll probably make it available as a patch too tomorrow or so (but the patch won't contain the tcp/ip stuff). 0.98 is essentially the same as 0.97.pl6 - the changes are mostly: - tcp/ip (0.8.1) is in. It's not compiled into the standard bootimage, and you'd better be on the tcpip mailing-list to use it, but it's there. I've been unable to test it further than just watch it compile... - extfs patch to correct the problem with big directories with holes. - mouse patches (ie improved detection-routines) - minor scsi patches (ultrastor driver change) - swiss keyboard - some serial driver patches - the 32mb patches are in, so if you aren't using a DMA-SCSI driver, and have more than 16MB physical memory, you can get it recognized. - edited hd.c - corrected core-dumping routines I didn't get my mm patches working yet, so they'll have to wait. The above are almost 100% by others - I have edited some of the patches, but there is nothing major new by me. Most of it is minor bug-fixes, and the only thing that might be a bit of a problem are the hd.c changes: but I hope they'll solve more problems than they cause. Knock wood. At nic.funet.fi you can currently find (a) the full sources (b) a bootimage (US keyboard, floppy root, no tcp/ip) and (c) the protocols.h file needed for compiling the tcp/ip directory (which should go into /usr/include/netinet/). I hope people try it out, and that there are no new problems with this release. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Where's Linus Message-ID: <1992Sep30.091651.29547@klaava.Helsinki.FI> Date: 30 Sep 92 09:16:51 GMT References: <1992Sep29.213232.7178@mcshh.Hanse.DE> Organization: University of Helsinki Lines: 23 In article <1992Sep29.213232.7178@mcshh.Hanse.DE> umisef@mcshh.Hanse.DE (Bernd Meyer) writes: >The subjext says it all - according to my newsreader Linus showed up >last on the 23rd of September - a week ago. >Is he off for holidays? >Did Bill Gates hijack(?) him? > >What has happened.... Oh, I'm here all right, and I've read all of c.o.l, but I haven't had much time/energy to do anything constructive. Also, I'm happy to say that most problems seem to be solved by others, and the rest of the discussion has been the 386bsd-linux flamewar which I didn't bother to respond to. I've also read all the mail I've gotten, although I've kept replies to a minimum. It also seems a lot of the linux-discussion has moved over to strictly user-level problems (and I couldn't be happier), and/or kernel problems I can't do much about (msdos fs problems etc). That is likely to change again now that 0.98 is out (already one report that the hd.c changes result in apparently harmless "unexpected hd interrupt" messages on one machine). Oh, well. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Xega and system lockup Message-ID: <1992Oct1.082802.13843@klaava.Helsinki.FI> Date: 1 Oct 92 08:28:02 GMT References: Organization: University of Helsinki Lines: 19 In article bobk@dogear.spk.wa.us (Bob Kirkpatrick) writes: > >I have a Logitech BusMouse... > >I've discovered that using ...tst/mouse/mouse produces the error >message "Stack Overflow on IRQ5" You are definitely using an older version of linux - try upgrading to either 0.97.pl6 or 0.98 (which will probably need the mouse-patch that was posted a day or two ago). The Stack overflow message is part of an older kernel (0.96c? something like that), and was fixed in 0.97. Note that 0.96c (which at least the current version of SLS seems to be based on) was a pretty stable release - but it is a bit old... Keeping up with the absolutely newest versions of linux may not be very safe, but there are problems with keeping to old kernel versions too. After all, I don't make new releases *just* to annoy people. Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: bootimage 98 boot video problems Keywords: 98 video bootimage Message-ID: <1992Oct1.212454.17196@klaava.Helsinki.FI> Date: 1 Oct 92 21:24:54 GMT References: Organization: University of Helsinki Lines: 20 In article perry@seq.uncwil.edu (Steve Perry) writes: >Hi, > I have been using Linux since .12 and have had no problems with my >monitor until .98. I went and got the bootimage-.98 from tsx, ftp'ed >it to my PC (in bin mode), uncompressed it, used rawrite to put it >on a floppy. Now when I boot from the floppy it runs thur the "Loading..." >line ok but as soon as it starts to print out the boot up stuff, the screen >loses it. Argghh ... Nothing wrong with 0.98 (that part hasn't changed for a while), but I compiled the bootimage with my monitor settings (ie "SVGA_MODE = -DSVGA_MODE=1" in the main makefile). This probably won't work on a non-VGA setup, and even with VGA you get the hardcoded startup mode, which is probably not what you want. The solution is probably to recompile the kernel with the SVGA_MODE line uncommented, or to wait until I (or somebody else) can get a new bootimage out the door. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: BUGS (even more minor) Message-ID: <1992Oct2.090825.5086@klaava.Helsinki.FI> Date: 2 Oct 92 09:08:25 GMT References: <1992Oct1.221854.36218@uservx.plk.af.mil> Organization: University of Helsinki Lines: 12 In article <1992Oct1.221854.36218@uservx.plk.af.mil> simonich@uservx.plk.af.mil writes: >It seems that the setting for NUM LOCK got lost when 0.98 Makefile >was released. It would be nice to have it back. It's there: I just rewrote the way the initial NUMLOCK is set. The default is numlock on, but you can set any default lock-values by defining the KBD_DEFLOCK define to whatever you want. So if you want no locks on by default, add a "-DKBD_DEFLOCK=0" to the main makefile line that defines the keyboard. Look into linux/kernel/chr_drv/keyboard.c for details. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: VERY DETAILED history of Linux in its early days Message-ID: <1992Oct2.090325.4664@klaava.Helsinki.FI> Date: 2 Oct 92 09:03:25 GMT References: <1992Oct2.005443.18476@sbcs.sunysb.edu> Organization: University of Helsinki Lines: 95 In article <1992Oct2.005443.18476@sbcs.sunysb.edu> synchem@sbcs.sunysb.edu (Synchem proj acct) writes: > >1. Does anyone still have a copy of Linux 0.01, or is it 0.11, > when all Linux does was switching two processes printing AAAA, BBBB...? > Or some very earliest version of Linux? The AAABBBB version certainly doesn't exist anywhere - that was long before I thought it was worth it to make it freely available. While 0.01 wasn't much, at least it *did* work as a simple unix clone. The oldest version that I was able to find with some fast ftp'ing was the 0.10 version of linux - and that most definitely did work (that's about the time when I tried to autodial my harddisk, and lost all my minix files...). 0.10 had some serious problems (no floppy driver if I remember correctly, and a bad bug in the buffer code), but it already ran gcc etc happily. And it's only 130kB in size - the current kernel is >600kB (but new drivers are a big part of that..) >2. An as detailed as possible description of things that are gradually > added to Linux since when it can only print AAAA, BBBB? And the design > decisions? I guess up detailed descriptions would be needed for only > up to 0.12. Things after that can most likely be found in textbooks. I've promised to write down what I remember (which isn't much) some time ago, but I haven't got around to it yet (writing not being my favourite pastime). Design decisions: none. Linux wasn't designed - it grew over a period of time, and I'm still impressed by how few bad decisions I've made so far (I've had to rewrite a lot, but nothing *really* broken). There were a couple of guidelines: keep it simple, and do it the easy way. On the other hand, I started with a pretty good idea of what I wanted, and I had the truly basic thing (multitasking) going at the very beginning. Stages (1991): - get into protected mode [Feb-Apr]. This isn't easy - especially if you are learning the assembly language and the quirks of the PC architecture as you go. This took several months (I made some small trials in this direction even before I got minix). Simple screen-IO came up here - mostly because that was the only way I could announce any kind of success. Poking a few long-words to screen memory and having a delay was the easiest way to show that the program had gotten enywhere. - multitasking. Getting a timer interrupt to work, and to switch between two tasks. This is where the first simple tty driver came into play, and when I printed out the AAA BBBB things. No memory management, no frills, just two different threads that got switched around by the 386 task-switching primitives. - basic drivers [May-June]. Mostly getting interrupts to work, refining the tty driver, getting the serial lines working (hardcoded to 2400bps until version 0.10 or so, because that was/is all I have). I used "linux" mostly as a terminal emulator by this time: it was written 100% in assembly, and did terminal emulation by having two threads: one read the keyboard and wrote to the serial line, the other read the serial line and write to the screen. By this time I had gotten confident enough about the system that I could start using C - but I think the console driver was in assembler until version 0.11 or so. I still had no harddisk drivers, no memory management and no filesystem. - basic harddisk driver, minix-fs, buffer cache [June-July]. These were somewhat intertwined: I needed all of them to be able to test things. The harddisk driver was first, then a simple buffer cache, then some basic fs routines. But they all got changed as other parts evolved. - basic system resources - mm, system calls, and refinement of the old parts [July - Aug]. This is where I started writing small linux programs to test out things. Mostly they were still hard-coded into the kernel - the system was still not up to a real fork/execve. I got there slowly, and eventually was able to port the minix shell to linux. Glorious day (but I've forgotten when this was :-). - basic enhancements - [Aug-91 - Sept-92] getting gcc to work (which really needs a working buffer cache..), porting basic utils, making it all available.. Getting X running, etc :-) Note that the above is a very much simplified history, and the dates are only "so-so" - they can be off by a month or two. Also, the developement wasn't as modular as the above would have you believe: that's just a rough timetable. And even when I first released it, 0.01 never really worked: it was just a source release (September-91?). >3. What are the considerations of in deciding what goes into kernel > and user space? As much as possible goes into user space, as long as it's not too much of a bother. If something gets much easier or cleaner (387-emulation) by being in the kernel, then so be it. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Readership report.. Summary: sept-92 readership Message-ID: <1992Oct2.103435.8586@klaava.Helsinki.FI> Date: 2 Oct 92 10:34:35 GMT Organization: University of Helsinki Lines: 62 In case somebody doesn't follow news.lists, here are selected parts of the september-92 readership reports. In case you want the full report, it's available in news.list along with some other general news-related reports. Interestingly, comp.os.linux propagation has gone up from just 56% to 71% within the last month. At the same time, the estimated total number of readers figures have become smaller by a noticeable amount - but not just for linux. There have probably been some changes to the way the readership is counted. For those that think linux is an active group: you are right. We aren't far behind alt.sex (THE newsgroup when it comes to popularity - although some other groups do have a bigger audience) in number of articles, and linux has been in the top 40 in both traffic volume and cost-per-reader for the last few months. As to actual popularity: propagation is still pretty low (80% is normal for a comp group it seems), but being the 335th most popular group isn't bad for this kind of specialized group. Linus --- edited list follows --- This is the full set of data from the USENET readership report for Sep 92. Explanations of the figures are in a companion posting. +-- Estimated total number of people who read the group, worldwide. | +-- Actual number of readers in sampled population | | +-- Propagation: how many sites receive this group at all | | | +-- Recent traffic (messages per month) | | | | +-- Recent traffic (kilobytes per month) | | | | | +-- Crossposting percentage | | | | | | +-- Cost ratio: $US/month/rdr | | | | | | | +-- Share: % of newsrders | | | | | | | | who read this group. V V V V V V V V 1 160000 5317 83% 980 1933.6 22% 0.02 11.5% misc.jobs.offered 2 160000 5142 82% 1568 1909.7 40% 0.02 11.1% misc.forsale 3 150000 4788 89% 10 157.9 100% 0.00 10.3% news.announce.newusers 4 120000 3910 68% 2556 6290.4 45% 0.07 8.4% alt.sex ... 20 68000 2241 86% 1120 2335.9 15% 0.06 4.8% comp.lang.c ... 69 44000 1448 85% 945 1622.4 15% 0.06 3.1% comp.unix.sysv386 ... 119 36000 1186 76% 1381 3445.7 2% 0.14 2.6% comp.unix.bsd ... 128 35000 1140 85% 534 902.9 11% 0.04 2.5% comp.unix.ultrix ... 262 25000 830 81% 10 11.1 10% 0.00 1.8% comp.os.misc ... 335 22000 733 71% 2392 4082.2 2% 0.26 1.6% comp.os.linux ... 365 21000 705 83% 139 327.0 5% 0.03 1.5% comp.os.minix ... 606 15000 498 76% 688 988.4 0% 0.10 1.1% comp.os.coherent ... 892 10000 345 79% 4 5.5 25% 0.00 0.7% comp.unix.sysv286 .. 1577 1500 48 9% 24 31.7 0% 0.00 0.1% houston.eats ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Once again -- FileSystem corruption Message-ID: <1992Oct4.074930.23728@klaava.Helsinki.FI> Date: 4 Oct 92 07:49:30 GMT References: Organization: University of Helsinki Lines: 28 In article mrex@aix01.rz.fht-mannheim.de (Martin Rex) writes: > >It still might be a problem with my Maxtor 7213 (PCBA rev 52 -- june '92) >but to me it looks like linux is maybe not fault-tolerant enough. Well, it's true that linux has some problems with bad spots on the disk (as I have never been able to see one...), but in the case of the maxtor drive (and you do have one of the early bad ones - PCBA < 63) it's just that the maxtor doesn't seem to *report* the errors, so linux doesn't even know about any trouble. The drive seems to work perfectly ok under DOS - but DOS (BIOS) doesn't even use interrupts in the harddisk driver. Does the maxtor work under OS/2? >I don't want to say linux is bad in any way, >but maybe it's possible to add some switches to offer conservative >timings for poor/flawed hardware ? There already is, both in {in,out}b_p() and in the HD_DELAY values. But with so many different systems (and so few hardware manuals), it's a bit difficult to please everybody. The default delay of inb_p/outb_p is four extra IO instructions - that is very conservative (at least my drive works without any delay at all). The HD_DELAY define isn't used by default: it's a pretty ugly hack, and I don't like it (but it does help some people, so...). Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Weird disk corruption (tar off msdos partition) Message-ID: <1992Oct4.072803.23147@klaava.Helsinki.FI> Date: 4 Oct 92 07:28:03 GMT References: <3835@ra.nrl.navy.mil> Organization: University of Helsinki Lines: 31 In article jefftep@cs.utexas.edu (Jeffrey Grills) writes: > > maxtor 7213a hd (never had any timeouts) > >I think there is some underlying problem. I've had tons of things weird >happen that have never had real solutions discovered for. For instance, >I think but cannot verify the following accusations: > > I've compared 2 files multiple times, getting 3 different results from cmp > I'm one of the people that gets Signal 11 from gcc/cc1 (still on occasion) > I've had the kernel complain about "swap weirdness" once (something like that) > I've done the cat|uncompress|tar thing and had tar complain about a bad input > file, only to try it again, with no changes, and have it work fine Definitely sounds like the buffer corruption problem with older maxtor 7213A's. Here is an excerpt from a post by swaliff@afterlife.ncsc.mil (Steve Aliff): > > Some of you may have been following my trials and tribulations with > a Maxtor 7213A under Linux. I spoke with Maxtor tech support today, > and they agreed that there was a problem with early 7213As and the > commercial variants of Unix (Xenix, SCO). If you have a 7213A whose > PCBA number is less than 63, then you may have a problem with it > under Linux. My present drive's PCBA number is 54. (The PCBA number > is their revision tracking number of the on-board controller board.) > The PCBA number is listed on the label on top of the drive. Upgrading to a newer 7213A helped at least Steve. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: unexpected interrupt? Message-ID: <1992Oct4.080658.24234@klaava.Helsinki.FI> Date: 4 Oct 92 08:06:58 GMT References: <1992Oct4.014156.11412@athena.mit.edu> Organization: University of Helsinki Lines: 42 In article <1992Oct4.014156.11412@athena.mit.edu> pmacdona@tadpole.bcsc.gov.bc.ca writes: >Sorry if I missed it, but is the fix to the "unexpected interrupt" >problem in .98 just to bump up the HD_DELAY? No, the fix is this one-line "patch" to linux/kernel/blk_drv/hd.c (at the end of the read_intr() function): ----- "patch" ----- if (i > 0) { SET_INTR(&read_intr); sti(); return; } + (void) inb_p(HD_STATUS); #if (HD_DELAY > 0) last_req = read_timer(); #endif do_hd_request(); return; } ----- "patch" ----- That is, add the "(void) inb_p(HD_STATUS)" line. Don't try to run the above through patch - do it by hand, or wait for the first "official" patch to 0.98 which has this and some other patches (possibly out later today). In case somebody wonders what happened to the hd-driver between 0.97.pl6 and 0.98: I removed the status-checking after reading the controller RAM buffer. Reading the status could (on some hardware with a fast disk) result in an acknowledge of the *next* interrupt, which linux would then wait in vain for. The above patch does read the HD_STATUS register - but it does so only after we have gotten all the interrupts we expect from the current read-request. So the above should (and does) fix the drives that need the inb() while not breaking anything else. 0.98 also has some other changes to hd.c, but those are mostly minor reorganizations of the read/write interrupt handlers. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: 8 bit console Keywords: kernel keyboard french patch Message-ID: <1992Oct5.164318.17472@klaava.Helsinki.FI> Date: 5 Oct 92 16:43:18 GMT References: <1992Oct5.025000.18463@sobeco.com> <1992Oct5.140408.25274@wam.umd.edu> Organization: University of Helsinki Lines: 15 In article <1992Oct5.140408.25274@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes: >What I was really asking is if the >kernel< is 8-bit clean. >E.g., can I use an 8-bit clean version of Emacs (which I have) to make >filenames with all 8-bits? There should be no problems with 8-bit characters anywhere in the kernel - but problems arise especially with current versions of bash as well as various other programs (even 'ls' needs the "--literal" flag to correctly print out 8-bit filenames). So while the kernel should handle them ok, I'd suggest against using 8-bit characters in filenames etc, as you'll have problems with 7-bit terminals, programs that cannot handle them etc etc. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Patch 1 for 0.98 out... Message-ID: <1992Oct5.170703.3832@klaava.Helsinki.FI> Date: 5 Oct 92 17:07:03 GMT Organization: University of Helsinki Lines: 15 nic.funet.fi: pub/OS/Linux/testing/Linus contains the first patch to 0.98 (along with a bootimage and the full source for those that don't like to patch). Patch1 to 0.98 mainly corrects some driver problems: it contains the added "inb_p(HD_STATUS)" for hd.c, as well as a changed mouse driver setup (hope it works - I couldn't test it..). There are also some SCSI driver patches: the seagate driver uses irqaction() to get irq's, and the aha1542 driver has the speedup patches. The bootimage should be compiled without the auto-SVGA mode, so people who had problems with linux automatically using a SVGA mode should be ok in this release. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Kernel Panic Message-ID: <1992Oct6.092442.29291@klaava.Helsinki.FI> Date: 6 Oct 92 09:24:42 GMT References: <1992Oct6.055750.8976@athena.mit.edu> Organization: University of Helsinki Lines: 25 In article <1992Oct6.055750.8976@athena.mit.edu> chchen@stat.fsu.edu writes: >After I installed 4 256k SIMMs to make my system 5 mb RAM, I've been >having kernel panic problems, especially after I stopped using the >modem. The message was: > >ldt[0]: 00000000 00000000 >ldt[1]: 0000ffff 00cbfb00 >ldt[2]: 0000ffff 00cbf300 >Kernel Panic: We don't support seperate I&D > >Any clue? I don't know what it means. This should definitely never happen - linux doesn't support separate I&D, and never creates a process that tries to use it. I put in the sanity-check just because I'm paranoid, and it seems to have paid off (and besides, everyone *is* out to get me). So the only reason I can come up with for this particular error message is that your RAM chips are too slow or have some other problems (bad connections, whatever) resulting in memory corruption. Alternatively, the kernel might be overwriting some of it's own data, but as the only change seems to have been your RAM-upgrade, faulty RAM does seem to be the likely solution. Try re-seating the SIMMS, or just remove them. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Compiling TIN doesn't work Message-ID: <1992Oct7.090155.16388@klaava.Helsinki.FI> Date: 7 Oct 92 09:01:55 GMT References: Organization: University of Helsinki Lines: 34 In article kkk@field.ichaos.nullnet.fi (Kristo Kaarlo Matias) writes: >My porting saga continues... Now it's TIN 1.1 PL1. "make sysv" produces >this: > >signal.c: In function 'set_signal_handlers': >signal.c:45: 'SIGBUS' undeclared (first use this function) >[...] >signal.c: In function 'signal_handler': >signal.c:102: 'SIGBUS' undeclared (first use this function) > >What the heck is this 'SIGBUS'? I didn't found it at /usr/include/*. Argghh. This comes up every once in a while (about twice a day to be exact), and the answer is that tin is not posix, and uses an obsolete signal that linux doesn't use, but which exists under both sysV and bsd, so most sources don't seem to bother checking about it. The thing to do is to search for SIGBUS in the sources, and put a #ifdef SIGBUS ... #endif around the offending code. It *could* be solved by adding a dummy signal value to /usr/include/signal.h ("#define SIGBUS 31" or similar), but the problem isn't really in the linux code but in the sources that assume SIGBUS is defined. >I have Linux 0.98 and GCC 2.2.2d. I compiled TIN with -DPOSIX_JOB_CONTROL, >is this ok? POSIX_JOB_CONTROL is ok. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Once again -- FileSystem corruption Message-ID: <1992Oct8.075539.22908@klaava.Helsinki.FI> Date: 8 Oct 92 07:55:39 GMT References: <1992Oct4.074930.23728@klaava.Helsinki.FI> <705559005snx@grendel.demon.co.uk> Organization: University of Helsinki Lines: 41 In article <705559005snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes: >In article <1992Oct4.074930.23728@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes: >> >> The drive seems to work perfectly ok under DOS - but DOS (BIOS) doesn't >> even use interrupts in the harddisk driver. Does the maxtor work under >> OS/2? >> >As far as I know, every BIOS hard disc driver does use interrupts. Hmm. I have only the IBM AT technical manual to check from (which does include the BIOS disassembly), and at least that BIOS (original IBM AT) does not use interrupts for the harddisk, but busy waiting (actually, the interrupt *is* used to set the flag that the BIOS is waiting on, but that's it). Linux does all the IO processing in the actual interrupt routine, which probably makes it a bit more timing-critical than some other solutions. > A >common problem with older BIOS's is that some IDE drives will raise the >interrupt on a read before the drive is actually ready to transfer data. >Older BIOS's often simply begin reading the data as soon as the >interrupt is received and in some cases - I found this with Quantam >drives, the data is replaced with garbage. Yes, linux had the same problem in earlier drivers (pre-0.96 I think), and there were some reports about trouble with Quantum drives. > The code needs to wait for >the interrupt to occur, then wait for the data ready flag in the status >register (or better still the alternate status register) before >performing data transfers. Linux already does this (but I don't see any reason for using the alternate status register - the function is exactly the same aside from accnowledging the interrupt). The problem seems to be something else with the maxtor drives - my guess is that the status register isn't always up-to-date or similar. I'm still looking into it and trying to find safe ways to make it a bit less timing-critical. Linus =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Chicken and egg: How was the first linux gcc binary created?? Keywords: gcc linux egg chicken soup Message-ID: <1992Oct12.100843.26287@klaava.Helsinki.FI> Date: 12 Oct 92 10:08:43 GMT References: <1992Oct10.124926.12423@engr.uark.edu> Organization: University of Helsinki Lines: 59 In article <1992Oct10.124926.12423@engr.uark.edu> tep@engr.uark.edu writes: > > As I was standing in the shower this morning I was thinking (I do >my best thinking in the shower) "How did Linus generate that first >gcc binary?" This was prompted by a newbie question about compilers >where he said something like "I can't compile a compiler until I have >a compiler to compile it." > > I guess Linus is the only one who can answer this but I figured it >would also be of general interest. So Linus, how'd ya do it??? As has already been noted, it's fairly easy to cross-compile gcc from one system into another, and that is what I did. The original gcc I used was the minix gcc (1.37.1) by Alan W Black (and somebody.. forgotten who?), which did some very ugly things in order to handle floating point. I used that to compile gcc-1.40 for minix, with patches by Bruce Evans to clean up the floating point handling and some of my own patches (I fooled around with gcc when learning about it, and added a "-mstring-insns" switch which allowed gcc-1.40 to use the 386 string instructions for structure copying etc). The minix-386 (thanks again, Bruce - without the 386 patches for minix I would never have gotten anywhere) I was running by that time was able to execute normal gcc binaries directly (the only major diff I did to minix - and awb later made a better version of it), which is also the standard linux binary format. So the same gcc binary running under minix could make both minix and linux binaries: the only thing that differed was the startup routine (crt0.o) and the standard library. My first binaries used modified minix library routines, and the first shell I used under linux (pre-0.01) was the minix bourne shell recompiled with those library routines. The binaries I later released used a library that was heavily based on Earl Chew's (free) estdio package (thanks), with some minor routines by me and some from various other sources (I think the minix termcap routines were free etc). Back then (0.01-0.11), the biggest problem with gcc were the libraries - estdio worked (even though it had it's quirks) but many other routines were either incomplete or missing. Porting many programs meant I had to write new library routines or find them from some other source (like the early and very buggy glibc.a). Also, I wasn't able to compile binaries under linux until version 0.10 or so - all the major first binaries (notably bash) were crosscompiled from minix. The reason was the bad buffer-cache bugs in early linux versions which made running gcc (which easily fills the buffer-cache) impossible. 0.03 was able to run a gcc binary, but recompiling gcc itself under linux led to weird crashes due to the buffer cache corruption. By 0.11-0.12, hlu had showed interest in maintaining gcc-2.x (I checked out early snapshots of the alpha sources), which meant I had to implement the math-emulation in the kernel, so that gcc wouldn't need the patches for integer floating-point. By that time glibc.a also started to be partly useable, so the linux libraries started using that more and more (with some bad bugs as a result in the early versions). The rest is history. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.unix.bsd,comp.os.linux Subject: Re: Binary compatibility question... [Summary] Message-ID: <1992Oct15.092205.28084@klaava.Helsinki.FI> Date: 15 Oct 92 09:22:05 GMT References: <1992Oct13.223537.11949@ucsu.Colorado.EDU> <1992Oct14.014146.20610@tfs.com> <1992Oct14.193014.537@ucsu.Colorado.EDU> Organization: University of Helsinki Lines: 25 In article <1992Oct14.193014.537@ucsu.Colorado.EDU> ngoh@rintintin.Colorado.EDU (NGO HIEN D) writes: > >From: Cameron Spitzer 764-6339 > >There *is* an "Application Binary Interface" for System V on the [34]86. >I was real disappointed to find out Linux doesn't use it. Don't know why he >doesn't either. The simple reason linux isn't even close the the intel ABI is that I simply hadn't got a clue about how it looked - intel never contacted me about it :-) and I certainly didn't want to go to any unnecessary trouble over it. As it turns out, the linux-ss project might be helped by linux following the intel ABI or at least being a bit closer (ie lcall 7,$0 for system calls), so I might put in some hooks for it - I'll take a look at the xenix emulator when I get some time. Making linux run most normal i386 ABI binaries would probably be pretty simple: you'd just need a simple wrapper around the system calls mechanism. To get more complete support, the signal handler stack frame would have to be changed etc, but very few programs care about that anyway. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Kernel panic!? Message-ID: <1992Oct15.093427.29150@klaava.Helsinki.FI> Date: 15 Oct 92 09:34:27 GMT References: <1biei2INN2mc@crcnis1.unl.edu> Organization: University of Helsinki Lines: 31 In article <1biei2INN2mc@crcnis1.unl.edu> mchapin@cse.unl.edu (Mark Chapin) writes: >In attempting to install the SLS package, I partioned my hard drive several >times using fdisk from Linux, DOS and even OS/2. After every attempt I use >mkfs -c /dev/hda2 57344 (with or without the -c) . No matter what I do I >get Kernel Panic: Trying to write bad sector. >Wassup? I have an ESDI 660 MB Seagate. The "trying to write bad sector" panic can happen if linux finds a drive it simply doesn't know how it might possibly read/write. The harddisk driver is unable to cope with more than 2 drives and/or more than 16 heads. The reason is that the st-506 programming interface only has one bit for drive identification, and 4 bits for head info. So if linux sees a disk that has more heads than 16, linux gives up with the above panic. If somebody knows how >16 heads are handled on the IO register level, I'd be interested to know. > I have partitioned it several >different ways. I am putting the Linux/Minix partition in a primary slot. >I have tried the turbo on/off. Any suggestions on what to try. I guess I >could try putting Linux as hda1, but I don't see how this would solve >the problem. Please HELP!!! No, using hda1 shouldn't make any difference. If your controller allows different sector translations, you might want to re-configure the drive using fewer heads, although that might then be a problem for the BIOS if the number of cyliders grow beyond 1024 (linux hasn't got this particular problem). Linus ================= ================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux: system failure - HD format - HELP - SOS Keywords: Linux HELP system failure Message-ID: <1992Oct16.145823.29423@klaava.Helsinki.FI> Date: 16 Oct 92 14:58:23 GMT References: Organization: University of Helsinki Lines: 38 In article wies@Informatik.TU-Muenchen.DE (Rene Felix Wies) writes: > >Well, I got the following error message: > > in /usr/src/linux/kernel/chr_drv: > I did a: touch *.c *.h > then a: make dep > followed by a: make > THE RESULT: > cc -c tty_io.c > cc -c console.c > console.c: In function 'scrup': > console.c: 360: fixed or forbidden register was spilled > This may be due to a compiler bug or to impossible asm statements. > make: ***[console.o] Error 1 You aren't supposed to run "make" by hand in the linux kernel subdirectories: the makefiles are set up so that a make in the base directory will compile the kernel. The message you are seeing has to do with the __asm__ statements in console.c - without optimizations gcc runs out of registers, and gives up. The correct optimizations and other compiler flags for the kernel are set up in the main makefile, and are needed to make a good kernel binary. Also, you seem to be running an older version of linux (0.96), which has problems with newer binaries (and also has some serious known bugs relating to both screen IO and the memory management routines). Try getting a newer version of linux (0.98.1 is ok, although it has some problems with busmice and some disk drives). The best way to then make sure the kernel is recompiled correctly is to set up all parameters (editing the main makefile to choose keyboard etc), and do a make clean ; make dep ; make to get a good kernel Image. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Questions about ... Message-ID: <1992Oct17.220153.3470@klaava.Helsinki.FI> Date: 17 Oct 92 22:01:53 GMT References: Organization: University of Helsinki Lines: 28 In article rickm@eng.auburn.edu (Rick Martindale) writes: > >Q1: I am still experiencing Unexpected hd Interrupt. I have read in > the past to bump up the HD_DELAY. This didnt fix it. Then I read > to add: > (void) inb_p(HD_STATUS) > to read_intr ( in hd.c ). I am running 0.98.1 and the line already > exist. Is there something else that needs to be done? Would it be > ok to simply comment out the print for the Interrupt message? Some drives (notably kalok and some NEC drive) give this message - they have given it for every single kernel version I've ever put out, and they seem still to work fine. If you don't see anything which looks like buffer corruption, commenting out the message is ok. >Q2: What is required to get ps running under 0.98.1? There is to my knowledge no 0.98 version of 'ps', but the 0.97.pl6 version should work (but may need recompilation and certainly needs updating with 'ps U'). >Q3: I am getting a core dump when I attempt a umount. Any Ideas. Try getting a new umount binary from (for example) the hlu [b|r]ootdisk, which should hopefully fix this(?). Haven't heard about this particular problem before, though. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Any mail or fakemail available for linux ? Message-ID: <1992Oct17.215224.3282@klaava.Helsinki.FI> Date: 17 Oct 92 21:52:24 GMT References: <1992Oct9.040601.23881@unlv.edu> <147770002@hplsla.hp.com> Organization: University of Helsinki Lines: 19 In article <147770002@hplsla.hp.com> ericb@hplsla.hp.com (Eric Backus) writes: > >I don't know the details of what the sticky bit does to a directory on >a SPARCserver. However, this still appears to be a security hole. >Here's what you could try to do: > > Move someone's mailbox to a different name. Even if noone else can > read it, you could now create fake mail for the original person. > Or you could put a non-writable file there to prevent the person > from ever receiving mail. With the sticky bit set, you cannot even move the mailbox, so this is not a problem. Although old versions of linux actually return the wrong error-value for this (ENOENT instead of EPERM), it has been enforced since about 0.96c, when somebody pointed this out to me. And 0.98.2 will correct even the error-return (thanks to this thread: I don't think I had actually tested it out before now :-) Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: ANNOUNCE: 0.98.pl2 is out Summary: New patches. Again. Message-ID: <1992Oct18.144546.28249@klaava.Helsinki.FI> Date: 18 Oct 92 14:45:46 GMT Organization: University of Helsinki Lines: 70 [ I already sent this to the mailing-list, nothing new, so skip this if you already saw it ] Patch 2 to 0.98 is out - it's available as both full source and as patches against 0.98.1 at nic.funet.fi: pub/OS/Linux/testing/Linus (and testing is still unreadable, so you have to cd to it blindly). patch-2 is >150kB compressed, as it contains several big changes. Most notable are: - the new FPU-emulator by Bill Metzenthen. It's bigger than the old one, but thanks to it, linux fpu emulation is no longer a quick hack, but a real emulator: it does all the 387(486) math instructions, and does them much faster than the old emulator + the soft library. The new math-emulator means that a separate soft-float library is no longer needed. It also makes even a non-coprocessor system pretty useful for limited math-calcs - the complex functions are much faster when they no longer have to be calculated using simple functions, and even the simpler instructions that my old emulator handled are faster using the new one. The size of the new emulator may mean that people who have little RAM, but do have a coprocessor should probably recompile the kernel with the emulator disabled. - various minor mm fixes by me: trapping kernel NULL dereferences, cleaning up the page table initializations and the 16MB patches, and various other bugfixes. get_free_page(GFP_ATOMIC) should preserve the interrupt flag, so malloc() should be safe now - hopefully no more of the tcp/ip memory management problems. The NULL pointer trapping may result in errors like: Unable to handle kernel paging request at address C0000??? Oops: 0000 ..... debugging info ..... There were several NULL pointer dereferences in the serial and tty drivers, which should now be fixed. I've also fixed any other errors I've seen, but if there are problems in the scsi drivers or similar things I cannot test, I'd like to hear about them. - scsi driver changes by Eric Youngdale. Preliminary support for removable media, and some bug-fixes. Due to white-space problems with eric's patches, the scsi patches are a bit bigger than necessary, but they should be ok even though I had to put them in partly by hand (and being unable to test them...) - The new tcp/ip patches that were sent to the NET channel not long ago. Yes, they are alpha, but so is the whole tcp/ip directory, so I put them in even thought they haven't been extensively tested (and they did have a serious problem in the ioctl code, which I fixed). - psaux mouse patches by Dean Troyer, as well as the mouse.wait = NULL patch. Before (or after) patching, you should remove the old math-emulator (ie "rm -rf /usr/src/linux/kernel/math") as it is no longer needed. You should also do a "make dep" to update dependencies: as usual, I edited out the dependancy-changes. Do a "make clean", edit the main (and net) Makefiles to suit your system, and compile. And finally: I will no longer be making the bootdisks available - they'll be made by hlu/jwinstead and will probably be boot+root-disks using lilo, as done on the hlu disks. That may mean that a bootimage won't be available at once, but most people who want to use the absolutely newest images probably compile them themselves anyway, so that shouldn't be a problem. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: ANNOUNCE: 0.98.pl2 is out Message-ID: <1992Oct18.224202.14619@klaava.Helsinki.FI> Date: 18 Oct 92 22:42:02 GMT References: <1992Oct18.144546.28249@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 40 In article <1992Oct18.144546.28249@klaava.Helsinki.FI> I wrote: > [ deleted ] > > - various minor mm fixes by me: trapping kernel NULL dereferences, ... Oh, boy. Talk about a feature that proved itself. I have never gotten so many bug-reports so fast: it seems there were quite a few NULL-pointer problems in the code I hadn't been able to test. Thus 0.98.2 isn't actually very useable unless you have a system very close to my setup - I don't recommend the faint-of-hearted to try it out. I guess I should be happy the new feature found problems in the kernel sources, but I could well have lived with a couple less problems. Main problem areas seem to be: - the vhangup() system call - used by newer login-binaries, and resulting in login getting killed. - some scsi driver problems (but they should be fixed by the patch eric already sent out) - tcp/ip problems - at least three different places where NULL gets dereferenced (and one is particularly ugly: it does test for NULL, but does so *after* dereferencing it...) The vhangup() problem was easy to correct (and excusable: it broke at least partly due to the new dynamic tty-routines). I'll make some preliminary testing-patches available that fix that problem, and includes the scsi fixes. But the tcp/ip code is a bit worse: I fixed two of the known problems, but I'd rather use patches from the persons who wrote the code originally, as there are some other problems in there.. And I can't be sure I find them all anyway, as I'll never see the problems first-hand. Just wanted to warn everybody about this aspect of pl2 - the NULL-pointer finding code is working a bit too well for my taste. I had hoped there wouldn't be quite this many NULL pointer problems, but at least they'll be found this way. Linus =============================== =============================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: ANNOUNCE: 0.98.pl2 is out Message-ID: <1992Oct20.090136.963@klaava.Helsinki.FI> Date: 20 Oct 92 09:01:36 GMT References: <719518170snx@kerberos.demon.co.uk> Organization: University of Helsinki Lines: 16 In article <719518170snx@kerberos.demon.co.uk> alovell@kerberos.demon.co.uk (Anthony Lovell) writes: > >Well look on the bright side if you couldn't find the bugs how would they >get fixed Oh, yes, the NULL-pointer finding code was definitely a good move: I have already received patches for (or fixed them myself with the help of reports sent in by others) at least 99% of the problems, and it seems to have resulted in at least the tcp/ip code working much better. I now have reports that X11 runs fine both to and from another machine under linux with tcp/ip, and I'll make 0.98.3 available in a few days after I have gotten some more reports. So I'm not complaining about the problems with 0.98.2 (although others probably are :-), but I would have been even happier if everything had worked 100% on the first try.. Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: tgif compiled, but what about SIGBUS? Keywords: tgif, signals, SIGBUS Message-ID: <1992Oct20.121054.401@klaava.Helsinki.FI> Date: 20 Oct 92 12:10:54 GMT References: <1992Oct19.153951.6649@lucrece.robots.ox.ac.uk> Organization: University of Helsinki Lines: 22 In article <1992Oct19.153951.6649@lucrece.robots.ox.ac.uk> jon@robots.ox.ac.uk (Jon Tombs) writes: > >I think bsd gives a SIGBUS if a user program does a inb() or outb() call, >this would seem to be more appropriate than SIGSEGV under linux. Actually, this isn't a good idea: linux would have to check why the protection error happened, and I don't think that is necessary or even something we want it to do. The current kernel setup just sees an error it cannot handle, so it sends a SIGSEGV. No special cases, no chacks why it happened etc. One good (or at least better) argument for SIGBUS being included (and one I have been thinking about) is that a 486 actually has an alignment trap, which under sysv-386 does seem to result in a SIGBUS (not that I have tried: just read about it somewhere). I haven't bothered about it, as I think the alignment trap is disabled under linux anyway. Besides, I don't see any reason for an alignment fault unless the processor really isn't able to handle unaligned transfers - but a 486 is perfectly capable of doing them, even if they are a bit slower. And gcc generally doesn't generate such code anyway. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: 0.98 and 0.98pl1 won't boot; will 0.98pl2 help? Message-ID: <1992Oct20.131421.14178@klaava.Helsinki.FI> Date: 20 Oct 92 13:14:21 GMT References: <1992Oct20.103029.3560@cs.tu-berlin.de> Organization: University of Helsinki Lines: 19 In article <1992Oct20.103029.3560@cs.tu-berlin.de> snake@cs.tu-berlin.de (Harald Schulze) writes: >When I try to boot Linux 0.98 or 0.98pl1 I get : >AX >BX >CX >DX >while the floppy is making lots of noise. > >This happens after "Loading..." when I have more than 80 '.' on the screen. This wouldn't be on a 360kB floppy, would it? Linux won't boot from one, so don't even try. Use a high-density (1.2M or 1.44M) floppy, and make sure there are no errors on it: the initial loading sequence is a bit picky about the floppy quality, and a bad floppy can also result in the above error-messages. If you get those kinds on messages on a HD floppy, try a new one, or at least reformat the floppy and re-rawrite linux to it. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Unix Books Message-ID: <1992Oct21.161022.18125@klaava.Helsinki.FI> Date: 21 Oct 92 16:10:22 GMT References: <1992Oct20.004410.24099@athena.mit.edu> <1992Oct21.121703.13670@ifi.informatik.uni-stuttgart.de> Organization: University of Helsinki Lines: 37 In article <1992Oct21.121703.13670@ifi.informatik.uni-stuttgart.de> weberj@dia.informatik.uni-stuttgart.de (Weber) writes: >In article <1992Oct20.004410.24099@athena.mit.edu> jwiegand@moe.eng.temple.edu writes: >> >>11. Title: The Design of the Unix Operating System >> Author: Maurice Bach >> Publisher: Prentice Hall >> Edition: 1986 >> ISBN: 0-13-201799-7 >> Comment: An excellent reference on the internals of System V ... >> This book and the next one are indeed highly technical ... >> >I have read in this book and I liked it. >My question: Is this book compatible with Linux, too (or the other > way round)? Well.. It was one of the books I used pretty heavily during early development, so there are certainly similarities: some of the algorithms (especially in the filesystem and buffer cache) the book describes are used in linux, and even function names can be similar. The book does lack in some areas (networking and job control) due to the sysv(r3) influence, but it's certainly a good book if you are interested in the unix kernel internals - I actually used the system call reference in the book as a check-list when implementing the basic linux system calls (along with ast's "OS Design and Implementation"). Another book I'd kill for (but haven't bought yet - it's a bit pricey) is Leffler et al's 4.3BSD internals book ("The Design and Implementation of the 4.3BSD system and..."). It covers the BSD system the same way Bach covers sysv, and has some pretty interesting chapters. I haven't been able to more than skim through it, but Linus says: "get it" if you can afford to and are interested in the intricacies of the BSD kernel. Neither of the above books are exactly "linux-compatible" (what a concept!), but they are the next best thing: good books about systems that have influenced linux heavily. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Q: List "Linux supporting Computers" ??? Message-ID: <1992Oct23.091550.28618@klaava.Helsinki.FI> Date: 23 Oct 92 09:15:50 GMT References: Organization: University of Helsinki Lines: 29 In article dingelde@igd.fhg.de (Dennis Dingeldein) writes: >Hi, >I just downloaded Linux 0.98.1 Bootdisk and 0.97 Rootdisk >from nic.funet.fi, transfered the stuff to DOS and executed rawrite >to write the stuff on disks. > >I tried to run Linux on three Machines (2x386 and 1x486) in my company. >One of them was a Compaq 386. >The Results were AS BAD AS POSSIBLE >Linux did not run on ANY MACHINE ! Hmm. While it's entirely possible that linux won't work on the machines (it does happen), the fact that it doesn't work on *any* of them makes me wonder about your boot-disk (and possibly root-disk) integrity. Linux does work on most AT-386's it seems, and the above seems a bit too unlucky (although at least some Compaq machines are known for doing things their own way: Compaq has this IBM-complex and thinks it can change the standards to suit itself. I think it's gotten better). The easiest way to prove there is no problem with a boot floppy is to find a computer it boots on: if you cannot, you should make sure you downloaded the images in binary mode all the way etc. If the bootimage is corrupted (or only partly written or similar: rawrite seems to have problems with some machines), the normal result is the reboot you describe. Don't be fooled by the fact that "Loading..." appears to work: that is handled by only the first 512 bytes, so even if they are good, the rest may not be. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: minix as a V86 task? Message-ID: <1992Oct23.093614.29238@klaava.Helsinki.FI> Date: 23 Oct 92 09:36:14 GMT References: <1992Oct23.031534.4907@cbnewse.cb.att.com> Organization: University of Helsinki Lines: 30 In article <1992Oct23.031534.4907@cbnewse.cb.att.com> sph1@cbnewse.cb.att.com (stephen.p.hill) writes: >I am going to take a class that requires a little Minix >programming ( either this spring or in the fall ) and I was >wondering if anyone ever tried to run Minix ( an 8088 version, >of course, not the 386 version ) under Linux. I realize that >the best solution would be to convince the teacher to use >Linux instead of Minix, but Linux does not come with a textbook.. > >It would be pretty neat if I could run 4 or 5 instances of Minix >under Linux, but I haven't got a clue if this is possible. >Anyone with the answer? Well, this sounded like a fun thing to try, so I tried starting the minix univeral boot version under the linux DOS-emu, in the hope that it would work as it uses the BIOS for most things. I'm afraid it doesn't. It actually gets as far as loading the kernel and printing out the minix copyright message and asking for the keyboard type. But after giving the correct keyboard, minix starts to do something to the DMA registers (I haven't looked at the source - but that's what the dosemu debugging info would seem to indicate), which the linux dos-emulator doesn't emulate at all. So when minix starts looping waiting for something to happen, it just sits there, and I killed it from another VC. So, no, it's not possible with the current emulator, and it would probably take a lot of work to get it working. Not impossible, but not a trivial project either. Linus ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: ANNOUNCE: 0.98.pl2 is out Message-ID: <1992Oct23.110949.4466@klaava.Helsinki.FI> Date: 23 Oct 92 11:09:49 GMT References: <1992Oct18.144546.28249@klaava.Helsinki.FI> <1992Oct23.101109.1433@mnemosyne.cs.du.edu> Organization: University of Helsinki Lines: 18 In article <1992Oct23.101109.1433@mnemosyne.cs.du.edu> mpevans@nyx.cs.du.edu (Mark Evans) writes: > >Is there a simple way to turn this NULL pointer trapping off? >So I have a machine I can login to >login: root >Unable.... >is not much use. There is a simple patch (removing one test in an if-statement in memory.c), but it's not a real solution to the problem, so I won't even post it here (I did post it to the NET channel as I wanted some response to some other problems with tcp/ip). 0.98.3 will correct all of these that I have so far gotten reports on (and the pre-version that is available to limited testers (ie the mailing-lists) corrects 99% of them). 0.98.3 will be out this weekend, so I'd suggest you wait two days for it. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux,gnu.misc.discuss Subject: Re: Copyright Message-ID: <1992Oct24.093456.7675@klaava.Helsinki.FI> Date: 24 Oct 92 09:34:56 GMT References: <1992Oct23.121845.25080@ringer.cs.utsa.edu> <1c8sihINNqm5@uwm.edu> Organization: University of Helsinki Lines: 33 In article sh2v+@andrew.cmu.edu (Stephen Hathorne) writes: > >Can anyone tell me a little more about the copyright involved with linux? >I am working on an application, and wish to use linux as the operating >system, (this will save my client about $500) > >I do not intend to charge for the operating system, but I do intend to >charge for the application, and support. This is no problem for the actual kernel: if you use linux you just have to make the sources available for the kernel - the copyleft doesn't matter for any programs running under linux (even if that would have been legal, which I doubt, it's not a restriction I would have wanted to put anyway). Money isn't the problem: if you wish, you can even charge for the operating system as well - as long as the kernel source is free and available from you once he's bought the binary. There might be some problem with the C library, however. Most of it is from the GNU libc.a, and as such is under the GLPL - this doesn't mean you have to give away your sources, but it does mean that you have to give the client a chance to re-link your binaries against a newer (or maybe just his own) version of the library. I think it's actually ok if you use the shared libraries with jump-tables (as then your binary doesn't contain any actual copylefted code), but maybe somebody who knows more about the GLPL should comment (which is why I crossposted to gnu.misc.discuss - hope this doesn't turn into yet another flamewar). Exactly due to these kinds of problems I made the actual linux low-level library routines totally free (ie the kernel interface hooks). So programs using those will not be encumbered, but they include only the basic unix system calls, and any real program uses many GLPL'd routines. Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Problem copying files with holes to msdos file system Message-ID: <1992Oct24.095215.8096@klaava.Helsinki.FI> Date: 24 Oct 92 09:52:15 GMT References: <9229816.15059@mulga.cs.mu.OZ.AU> Organization: University of Helsinki Lines: 23 In article <9229816.15059@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes: >I've mounted my DOS partition using "mount -t msdos /dev/sda1 /dos", >and most things work fine. But I have had trouble copying some large >from the Minix file system to the DOS file system. When I try to >copy my boot image file across, using "/bin/cp /linux-0.97.1 /dos/linux-97.1", >it goes into an infinite loop. I can't kill the process even with kill -9. >The hard disk is being continually accessed, and performance on the >other virtual consoles is terribly slow. "ls -l /dos/linux-97.1" shows >the file size to be only 3072 bytes. You are right: older versions of the msdos fs have problems with holes in files. The easy solution is to upgrade: 0.98.x shouldn't have this bug. >Another problem of unknown cause: I tried moving a few large files from >the dos file system to the minix file system using /bin/mv, and the >system spontaneously rebooted in the middle of executing the command. >I don't seem to be having much luck at the moment :-( This one too seems to be gone: I just copied over 1M+ files with 'mv' to check it out, and it doesn't happen for me. Upgrade time. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: will linux use swap partition AND swap file at the same time Message-ID: <1992Oct24.181041.17174@klaava.Helsinki.FI> Date: 24 Oct 92 18:10:41 GMT References: <1cc0gqINN673@usenet.INS.CWRU.Edu> Organization: University of Helsinki Lines: 28 In article <1cc0gqINN673@usenet.INS.CWRU.Edu> mal11@po.CWRU.Edu (Matthew A. Lewis) writes: > >I need 16MB of swap and my partition is only 8MB. >Can I make an 8MB swap file or do I have to disable the swap >partition and make a 16 MB swap file?????????? No problem if you are running a relatively recent kernel: you should be able to use both a swap-partition (for good performance) and a swap-file (for the overflow that won't fit into the partition) at the same time. Just do: - create the swapfile (needs to be done only once): # dd if=/dev/zero of=swapfile bs=1024 count=8192 # mkswap swapfile 8192 - enable swapping (usually at bootup): # swapon /dev/hdXX # swapon swapfile Note that you had better enable the partition first - linux doesn't do any clever swap-space striping or similar, but instead uses up the swap-pages in the order they were installed. So enabling the partition first means that it gets "preferred status", which is generally what you want (as it's noticeably faster to swap to a partition). Linus ================= ================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Linux - the future? Message-ID: <1992Oct25.172207.11981@klaava.Helsinki.FI> Date: 25 Oct 92 17:22:07 GMT References: <1992Oct25.144134.19612@cs.hw.ac.uk> Organization: University of Helsinki Lines: 88 In article <1992Oct25.144134.19612@cs.hw.ac.uk> scottd@cs.hw.ac.uk (Scott Dunn) writes: > >How do you, Linus, see Linux developing? >I have to admit that this is the one concern I have always had about Linux. >You are, I think I'm right in saying, a student. Developing Linux can't be >your main concern at this point in time, unless of course you've managed to >tie it in with your course. Actually, it's so far been the other way around: studies haven't been my main concern at this point of time unless I've been able to tie them in with my linux-hacking. Only half-joking - it really isn't linux that has lost time due to other things.. > Do you intend taking it as far as 1.0 and then >leaving it in the hands of the Linux community to take it further? 1.0 has never been any magic number - I don't intend to stop there, and the only reason I have delayed it is because there has always seemed to be yet another important feature or bug-fix "any day now". My current setup is much better than I originally envisioned 1.0 - but even that doesn't mean I'm thinking of quitting. There was some talk on the mailing-lists (actually, just one list back then) around version 0.12 about me stepping down in case somebody else (or some group like the FSF) wanted the job, but nobody seemed even slightly interested, and I haven't heard any complaints about the current state of affairs yet. It seems people prefer having somebody as a final arbiter on what goes in and what doesn't, and I've been the natural choice so far despite some of the problems (mostly due to lacking hardware). >Are there plans to make it SVID (System V Interface Definition) binary >compatible? I've been idly thinking about it: the biggest problem has been lack of docs and programs. In any case, I don't feel binary compatibility is very high on my list, and I'd rather delay it until the kernel seems to be a bit more stable ("stable" in the meaning not-changing as opposed to "crashing every minute"). I'm not against binary standards, but I'd implement it more as a shell around the "real" linux kernel than as a integral part of the kernel. I've always been pro-standard: mostly POSIX, as that has meant porting is easy, and that has been the only thing I've been interested in, as I don't have any sysvr4 binaries anyway. I don't think this will change: linux will probably be able to accomodate future standards faster than systems that don't come with source code. After all, being freely available has resulted in the current system in "record time" (or then I'm just such a helluva programmer - take your pick :-) >What features are missing from Linux? On a user level, the worst actual missing features are probably related to memory management: the linux memory manager is still just three (not even very big) files, and while it's clever, it's not very general. So things like shared memory and a real mmap() are still not there, although I've been looking into it for some time now. Internally, the socket code isn't very well integrated with the rest of the kernel - I'd like something more general. But there aren't any major features missing: the networking code may not be quite stable yet, but that's just a matter of time, as the basic things are there. >If you, Linus, are unable or unwilling to continue developing Linux >in the future would the handover of Linux to FSF be an option? The day people think linux would be better served by somebody else (FSF being the natural alternative), I'll "abdicate". I don't think that it's something people have to worry about right now - I don't see it happening in the near future. I enjoy doing linux, even though it does mean some work, and I haven't gotten any complaints (some almost timid reminders about a patch I have forgotten or ignored, but nothing negative so far). Don't take the above to mean that I'll stop the day somebody complains: I'm thick-skinned (Lasu, who is reading this over my shoulder commented that "thick-HEADED is closer to the truth") enough to take some abuse. If I weren't, I'd have stopped developing linux the day ast ridiculed me on c.o.minix. What I mean is just that while linux has been my baby so far, I don't want to stand in the way if people want to make something better of it (*). Linus (*) Hey, maybe I could apply for a saint-hood from the Pope. Does somebody know what his email-address is? I'm so nice it makes you puke. Don't worry, though: this is just my net-personality, and in real life I kick furry small animals for fun. =================== =================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: 0.98.3 is late ... Message-ID: <1992Oct26.050726.2504@klaava.Helsinki.FI> Date: 26 Oct 92 05:07:26 GMT Organization: University of Helsinki Lines: 16 ... as you probably all have noticed. I've been up all night writing this report for the "CS Course from Hell" (*), and haven't had time to play with linux. I'll get it done tonight if I can keep awake that long. In case anybody still wonders, 0.98.3 mainly fixes the NULL pointer and most of the serial line problems. I also started to remove some of the more unnecessary cli-sti pairs (where races could be avoided by doing it some other way), so it's possible interrupt latency is better, but I doubt it's noticeable. Linus (*) Well, they call it "ATK-suunnittelun laboratorioty|", but they aren't fooling anybody. ================ ================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: 0.98.3 finally available Message-ID: <1992Oct27.040101.28497@klaava.Helsinki.FI> Date: 27 Oct 92 04:01:01 GMT Organization: University of Helsinki Lines: 10 0.98.3 is available at nic.funet.fi: pub/OS/Linux/testing/Linus as diffs against 0.98.2 (linux-0.98.patch3.Z) and against the pre-release that was announced on the mailing-lists (pre-final.diff.Z). I haven't uploaded the complete sources yet, so diffs are all there is: I'll upload the full sources once I've gotten some more sleep. 0.98.3 corrects a lot of NULL-pointer bugs, as well as some other problems (notably serial lines). Hope this release will be stable, Linus ===================== ===================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: I can malloc more memory than I have.SKIP Message-ID: <1992Oct27.105511.17819@klaava.Helsinki.FI> Date: 27 Oct 92 10:55:11 GMT References: <1992Oct26.083011.17192@fys.ruu.nl> <1992Oct26.180801.28536@sfu.ca> <1992Oct27.124302.90427@vaxc.cc.monash.edu.au> Organization: University of Helsinki Lines: 30 In article <1992Oct27.124302.90427@vaxc.cc.monash.edu.au> johnhm@vaxc.cc.monash.edu.au writes: > > I think the problem is more general than just running out of virtual memory. >It seems as though code that runs in the kernal can realy hog the the machine >to the exclusion of all else. > For instance, when running X11perf without a coprocessor the machine will seem >to grind (almost) to a halt during some of the tests (probably ones using >circular functions heavily). Lack of memory doesn't seem to be the problem >here as there is no swapping going on (which top confirms whenever it gets a >chance to run). It seems a bit strange if the kernal is blocking other processes >even if it's just doing floating point emulation. I wonder if this extends to >everything the kernal does? While it's true that a kernel process won't be rescheduled while it still runs, this should be no problem: all the system calls, traps and interrupt handlers are designed to cope with that (although there may actually be some busy waiting in the SCSI-driver). The reason x11perf seems to bring the machine to it's knees is not that the kernel hogs all the time, but because X11 itself is busy calculating things - while the X server does it's calculations, it won't do other screen updating... The core-dumping mis-feature when running out of swap is a pity - I might try to make this a special case so that no core will be generated for this case (you don't do much with a core-file anyway: it wasn't exactly a program bug that resulted in it being terminated). In the meantime, setting the core-size to 0 (ulimit -c 0) is the preferred option unless you are actively debugging something. Do it in your .profile, and you'll never see another core again.. Linus ====================== ====================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: ANNOUNCE: linux-0.98.3 Message-ID: <1992Oct27.194952.14193@klaava.Helsinki.FI> Date: 27 Oct 92 19:49:52 GMT Organization: University of Helsinki Lines: 59 Ok, I already sent out an announcement last night, but due to the time (6AM over here) I wasn't really in a mood to write a real annoucement. Here it is. linux-0.98.3 is available by anonymous ftp at least on nic.funet.fi: pub/OS/Linux/testing/Linus, both as context diffs against 0.98.2 and the pre-version of 0.98.3 and as complete source. The complete source package was done by directly applying the diffs - this means that the Makefile dependancies are probably not 100% up-to-date as I remove those from the diffs. It shouldn't be any problem, and you can always do a "make dep ; make clean" before actually compiling the kernel. 0.98 pl3 fixes several bugs, and should remove all known NULL-pointer problems that made 0.98.2 unusable for most people. In addition to the NULL pointer fixes, the following things have changed: - removed most of the cli-sti pairs in the filesystem code by rewriting the locking routines to use a different algorithm, possible due to the rewritten wait-queue code that I did back in 0.96c or so. Interrupt latency should be better on slow machines, but I don't know if it's noticeable. - Minor 387-emulation fixes by Bill Metzenthen - only noticeable under special conditions. - Corrected various error-returns in the fs (thanks to Bruce Evans for running some error diagnostics). Error messages when opening (and renaming etc) files that had a non-directory in the path were wrong, and should be ok now (ie giving ENOTDIR instead of EACCESS or ENOENT). Some other problems reported by Bruce fixed. - Changed the interface for some fs-related functions due to cleaning up super-block handling. Most noticeably, iget() and related functions no longer specify the inode with a device and inode number, but instead with a super-block pointer and inode number. This is more logical, and should make unnamed devices (ie internal filesystems like nfs and /proc) cleaner. Also note that the calling sequence for sb->s_op->put_inode() also has changed since 0.98. This is of interest only if you are writing filesystem drivers.. - ASK_SVGA was broken in 0.98.2 - it should be ok now. Also, various minor fixes as usual. No new features, but I hope 0.98.3 will be a lot less bug-prone due to the changes since 0.98.1. Some minor tcp/ip corrections (but most of them were in the pre-release), and I removed a race-condition in the tty-handling code. Note that people who use math without a co-processor should certainly upgrade to 0.98.3: the new emulator is much better than my original one both in speed and accuracy/exception handling. x11perf is very much bearable now even without a 387, and things like ray-tracing etc shouldn't be a problem any more. It's slower than hardware fp, of course, but at least it works. The new emulator also means there is no reason for a separate soft-float library, so I'd assume that will be gone in the next gcc release for linux. As usual, a new kernel version probably means you'll have to recompile 'ps' and friends. But at least the same 'ps' sources that worked for 0.97.6 should still work. Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: MAJOR bug in mount in 0.98.3 Message-ID: <1992Oct29.121938.16664@klaava.Helsinki.FI> Date: 29 Oct 92 12:19:38 GMT Organization: University of Helsinki Lines: 66 Sorry everybody, but pl3 has a major bug in mounting related to the caching of inodes - they are searched according to inode number and the super-block they are associated to (so far so fine), but the super-block info is not correctly updated when mounting/umounting a filesystem. This is not normally noticeable (bad excuse) as most people (including me) mount things just once, but if you umount and remount something, it can lead to MAJOR filesystem corruption. Thanks to hlu, who found this (sadly destroying his fs in the process..) The fix is in linux/fs/inode.c, in the function 'fs_may_mount()'. It looks like this: ----- "patch" follows ----- int fs_may_mount(dev_t dev) { struct inode * inode; for (inode = inode_table+0 ; inode < inode_table+NR_INODE ; inode++) { if (inode->i_dev != dev) continue; if (inode->i_count || inode->i_dirt || inode->i_lock) return 0; inode->i_dev = 0; + inode->i_sb = NULL; } return 1; } ----- end of "patch" ----- ie, just add the "inode->i_sb = NULL;" line to the function. That should fix the problem. Another problem (also found by hlu) is in linux/kernel/chr_drv/serial.c, where an 'outb()' statement has the order of the argumebts mixed up. The offending line is in the function set_modem_info(), line 778, and it looks like this: ----- begin "patch" ----- default: return -EINVAL; } ! outb(UART_MCR + port,control); return 0; } ****** default: return -EINVAL; } ! outb(control, UART_MCR + port); return 0; } ----- end "patch" ----- ie, just swap the 'control' and 'UART_MCR + port' arguments. Neither of the above is a "real" patch in that you have to patch it by hand, but I haven't had time to do those yet (and I'll try to find some other bugs while I'm at it). But if you have 0.98.3, *PLEASE* apply them, or use an older version. Sorry for the new bugs, Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Strange minix fs problem: duplicate core files in directory! Message-ID: <1992Oct30.155235.18870@klaava.Helsinki.FI> Date: 30 Oct 92 15:52:35 GMT References: <1992Oct30.050149.28125@cheshire.oxy.edu> Organization: University of Helsinki Lines: 40 In article <1992Oct30.050149.28125@cheshire.oxy.edu> rafetmad@cheshire.oxy.edu (David Giller) writes: >I just ran into a strange problem with the minix filesystem. When >dumping core files under X, linux created two files (different, not >identical) called "core" in my home directory. > >Here's the whole explanation: > >I installed SLS 0.98 a week ago, and have since patched the kernel up >to 0.98.3. Rebooted, did an fsck, and started up X. > >I created a 4Mb swapfile, and swapon'ed it. I started up about 10 >clients. > >Then, for fun, I did a swapoff on the swapfile [ deleted ] Ok, it's due to a race-condition in the filesystem - I haven't bothered to fix it for the simple reason that it almost never happens (and it's bothersome to fix completely), but the above sure is one way to make the system have some problems. Doing a "swapoff" when you don't really have enough memory isn't a good idea, although nothing should really break (linux tries very hard to stop swapping by writing out executable pages etc - that's why you get all the disk accesses. And as you noticed, some of the programs may be killed off). You can create several files with the same name in the same directory just by stressing the system very hard and trying to create files with the same name. It's a harmless way to have some fun on your system: the files are distinct but have the same name so you could possibly confuse some programs with it. You can delete them one-by one, or simply rename them: doing a rename on the name will rename the file that is first in the directory, while the other will still have the old name. It's fun to mess with the minds of innocent programs by doing these kinds of stunts - has anybody tried tarring such a directory? Note that it isn't exactly easy to create these kinds of duplicate names: you really have to swap pretty badly. I guess I should document it and add it as a "feature" to linux: it's harmless enough that I probably won't try very hard to get it corrected. Linus ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Strange error with 0.98.3 and X11 Message-ID: <1992Oct30.155953.19088@klaava.Helsinki.FI> Date: 30 Oct 92 15:59:53 GMT References: <1992Oct30.120931.3085@ultb.isc.rit.edu> Organization: University of Helsinki Lines: 16 In article <1992Oct30.120931.3085@ultb.isc.rit.edu> axi0349@ultb.isc.rit.edu (A.X. Ivasyuk) writes: > >I'm getting a strange error when I exit X and it restores the text screen. >It says, "ERROR: wm-FPU-emu is not RE-ENTRANT!". This doesn't stop X from >running, but I'm wondering what this is all about... Yes, there is a bug with respect to re-entrancy in the new math-emulator. It has to do with several emulator-instances being active at the same time due to demand-loading or swapping, and might be a problem for some (but it's timing-dependent as well, so you won't necessarily see it..). I hope to have it fixed for the next release, but it shouldn't really break too much software even now. X11 is more of a problem than most things due to the fact that most people swap a lot more under X than they normally do. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: [BUG]: (seems so ...) 0.98pl3 Message-ID: <1992Oct31.220649.27337@klaava.Helsinki.FI> Date: 31 Oct 92 22:06:49 GMT References: <1992Oct31.051350.1188@utstat.uucp> Organization: University of Helsinki Lines: 23 In article <1992Oct31.051350.1188@utstat.uucp> rafal@utstat.uucp (Rafal Kustra (summer student)) writes: >Moving to .98pl3, from .97pl4 couses TeX to abort with: >No inode #/device # in parent directory. As a rought guess, I'd assume this is with an old binary that tries to read the directories "by hand" instead of using the readdir() system call. This happens if it was compiled with something before gcc-2.2.2, so I thought it wouldn't break anything to disallow that in the new release. As it turns out, more people are using old binaries than I though, but I won't re-enable it: reading a directory is not a good idea and will break on any non-minix filesystems anyway. So the fix is probably just to recompile TeX or get a newer binary from some place (but I haven't kept up with TeX: no diskspace). The same problem also seems to plague some kermit binaries - the symptoms seem to be that "set line" doesn't work as expected. You can also see the new behaviour more easily by just doing a "cat ." using both the old and new linux kernels. With the old kernels, this results in a messy display of the directory contents on a minix-fs, whereas 0.98.3 gives the error message "cat: .: Is a directory". Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: SLS 0.98p1 vs Logitech Busmouse (death via wake_up()) Message-ID: <1992Oct31.231854.28578@klaava.Helsinki.FI> Date: 31 Oct 92 23:18:54 GMT References: Organization: University of Helsinki Lines: 29 In article ingima@ee.ualberta.ca (Darin Ingimarson) writes: > > Well, I haven't got this beat, but I'm far from giving up. Many thanks >to Bob Kirkpatrick for his help on this. Here is what I've found out so far: > > The logitech mouse driver snuffs it in the mouse_int() routine at the >wake_up() call. What I am humbly requesting is someone who knows a bit more >about the mouse driver and Linux scheduling to answer a couple of questions for >me before I get back at it (I've written many a device driver and done lots of >system level bughunting in a UNIX-like RTOS, so I'm not a complete techno- >turnip... just not much experience with things like select(), *NIX interprocess >security, etc.). > > It seems to me (from perusing Linus' source) that this wake_up() call >suggests to the scheduler that it might want to wake up any proceses waiting >on a mouse interrupt. Why would wake_up() die if no processes are waiting >on the interrupt? Shouldn't wake_up() just see that nothing is waiting and go >on with things? wakeup() works fine even if there aren't any jobs on the queue: this particular problem is due to there being *bogus* jobs on the queue, as the wait-queue pointer is never initialized to NULL in 0.98.1. The easy fix is just to initialize the wait-queue correctly, or indeed just get 0.98.3 which does it correctly. Also, using new versions of LILO will result in the kernel bss being automatically cleared, and the problem goes away. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: linux-0.98.3 termcap problem Message-ID: <1992Nov1.101439.10943@klaava.Helsinki.FI> Date: 1 Nov 92 10:14:39 GMT References: <1992Nov1.004828.6310@afterlife.ncsc.mil> Organization: University of Helsinki Lines: 18 In article <1992Nov1.004828.6310@afterlife.ncsc.mil> jepstei@afterlife.ncsc.mil (John Epstein) writes: > >QUESTION: Besides fs and math emulation, was termcap >supposed to affected by 0.98.2 or 0.98.3 >I assume null-pointer would generate an error. Arggh. Yes, the kernel did change some terminal info in 0.98.3 - namely the standard TERM variable. Instead of using the "con80x25" etc names (which resulted in terrible /etc/termcap files), 0.98.3 initializes TERM to be simply "console". The terminal size is available from the termios size structure, and is no longer encoded into the terminal type name. So if you seem to have problems with termcap, make sure you have an entry for "console" which essentially looks like vt100 or vt220. That should be the default (well, it was in *my* termcap even before I did the changes to 0.98.3), but it may not be true of all systems. Linus ======================= ======================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: QUERY: raw floppy devices? Message-ID: <1992Nov3.104745.13480@klaava.Helsinki.FI> Date: 3 Nov 92 10:47:45 GMT References: <2AF55E71.5AA1@tct.com> Organization: University of Helsinki Lines: 14 In article <2AF55E71.5AA1@tct.com> chip@tct.com (Chip Salzenberg) writes: >Is there a technical reason not to support /dev/rfdX devices? It >seems like a Bad Thing to force one-time floppy accesses (like, say, >disk copies with "dd") into the buffer pool. No technical reason unless you count simplicity. When I wrote the original drivers I didn't want to bother with both raw and buffered access, so I settled for just the buffered routines. I haven't seen enough reason to regret that yet: using the fs buffers does fill them up unnecessarily in some cases, but I haven't really found it to be a bother (mostly the reverse: no need to bother about blocking factors for good floppy speed etc). Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: USENET Readership report for Oct 92 Summary: edited for c.o.linux Message-ID: <1992Nov3.125211.20525@klaava.Helsinki.FI> Date: 3 Nov 92 12:52:11 GMT Organization: University of Helsinki Lines: 54 Ok, I don't know if anybody was very interested last month either, but in case people want to know and don't read the news.lists group, here is the latest (edited) popularity info. Additionally, linux once more showed up in the top-40 lists in both volume and per-reader cost. This month yet another milestone was reached: note the "Recent traffic" fields (both in kilobytes and number of messages): c.o.linux is actually more active than alt.sex according to newsstat. c.o.linux was nr 31 in traffic volume in kB - actually the biggest non-binary "technical" group it would seem. Linus ---------- This is the edited set of data from the USENET readership report for Oct 92. Explanations of the figures (and the full lists) can be found in 'news.lists'. +-- Estimated total number of people who read the group, worldwide. | +-- Actual number of readers in sampled population | | +-- Propagation: how many sites receive this group at all | | | +-- Recent traffic (messages per month) | | | | +-- Recent traffic (kilobytes per month) | | | | | +-- Crossposting percentage | | | | | | +-- Cost ratio: $US/month/rdr | | | | | | | +-- Share: % of newsrders | | | | | | | | who read this group. V V V V V V V V 1 190000 5837 90% 10 158.1 100% 0.00 12.1% news.announce.newusers 2 160000 4971 83% 1002 1958.2 17% 0.02 10.3% misc.jobs.offered 3 160000 4965 82% 1666 2087.5 36% 0.02 10.3% misc.forsale 4 130000 4015 68% 1752 4192.5 41% 0.04 8.3% alt.sex 5 120000 3855 84% 6 262.9 67% 0.00 8.0% news.answers ... 20 75000 2331 87% 1294 2465.0 16% 0.05 4.8% comp.lang.c ... 94 41000 1289 84% 90 120.8 30% 0.00 2.7% comp.unix.misc ... 114 39000 1197 77% 1251 2943.9 5% 0.11 2.5% comp.unix.bsd ... 171 33000 1016 86% 593 928.1 13% 0.05 2.1% comp.unix.ultrix ... 256 27000 842 72% 2890 4755.9 4% 0.24 1.7% comp.os.linux ... 279 26000 801 83% 880 1465.3 8% 0.09 1.7% comp.unix.aix ... 297 25000 784 82% 23 35.4 9% 0.00 1.6% comp.os.misc ... 385 22000 690 83% 163 1094.1 3% 0.08 1.4% comp.os.minix ... 543 18000 554 49% - - - - 1.2% comp.unix.pc-clone.32bit ... 689 15000 478 76% 526 887.8 1% 0.09 1.0% comp.os.coherent ... 1640 1600 49 10% 13 137.4 0% 0.02 0.1% de.newusers ==================== ==================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.unix.bsd,comp.os.linux Subject: Re: Port of new Linux math emulator to 386bsd? Keywords: math emulator, port Message-ID: <1992Nov4.111732.9703@klaava.Helsinki.FI> Date: 4 Nov 92 11:17:32 GMT References: <1992Nov4.021453.22896@citec.oz.au> Organization: University of Helsinki Lines: 16 In article <1992Nov4.021453.22896@citec.oz.au> sgccseh@citec.oz.au (Steve Hocking) writes: > > Looking at the latest Linux release and user comments on it, it >appears that a new math emulator has been written which is more complete and >accurate, plus about 2x faster. Does anybody have plans to port this to >386bsd (since we got the original emulator from Linux anyway)? The problem is the copyright: it's copylefted code by Bill Metzenthen, so you cannot distribute it under the 386bsd copyright. The original emulator I wrote was also originally copylefted, but I gave Bill and Lynne the right to use it under 386bsd (the copyright was changed to something like "freely usable for the 386bsd and linux projects"). You'd have to ask permission from Metzenthen - his email address can be found in the sources. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Re: Free UNIX for sale Message-ID: <1992Nov4.162315.26780@klaava.Helsinki.FI> Date: 4 Nov 92 16:23:15 GMT References: <73559@hydra.gatech.EDU> <1992Nov4.140106.3873@fwi.uva.nl> Organization: University of Helsinki Lines: 16 In article <1992Nov4.140106.3873@fwi.uva.nl> stolk@fwi.uva.nl (Bram) writes: >gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >> >> --> 386BSD Version 0.1 & LINUX Version 0.96...............$100 <-- > >Gee, Linus and other contributors, >I dont know about you, but I would be pissed off, if someone >started making money on the stuff I worked so hard at. Why be pissed off? It's really a compliment. And believe me: getting money may be fun, but when you get T-shirts, virtual beer, book offers and enough money to pay off your computer, *even without asking for it* (dropping a few hints, maybe ;-), it's worth a lot more. Hey, I might no get rich on linux, but I'm certainly being poor with style, eh? Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.linux Subject: Thanks... Summary: finally paid off my computer Message-ID: <1992Nov5.094730.28084@klaava.Helsinki.FI> Date: 5 Nov 92 09:47:30 GMT Organization: University of Helsinki Lines: 16 Just a quick note to say "THANKS" to everybody - today I was able to finally pay off my computer using money collected by hpa (Peter Anvin) from various people. The collection brought in USD $750, and together with some other donations (including a fim 1000 EuroCheque) I was able to pay the final rate today. I'd also like to thank everybody else who has sent me either money or any other encouragement (ranging from postacards and T-shirts (!) to beer-money and actual beer). I'm not making a "hall of fame" of people who have paid me money: I might forget somebody (who'd hate me for the rest of his life), and anyway, contributions in the form of patches/bug-reports etc have been at least as valuable (and I haven't kept track of those either. Shame on me). You know who you are, thanks, Linus ================================ ================================ ################################